Stream to HQPlayer Desktop from foobar2000

[Miska]

Modifying the current foobar plugin to perform better in this use case probably wouldn't be hard. I don't know if it is open source, otherwise someone would need to ask the original developer...

[Miska]

Miska, I got this answer from the author:

 

He didn't seem to understand the proposal. foobar could cut the stream when input sampling rate changes and replace it with a new one at the same URL but with different parameters. This only needs to happen when format changes, as long as format doesn't change, there's no need to do anything and it can be "infinitely" long stream....

 

Doing such should be relatively easy to implement.

[Miska]

Perhaps the priority is to serve the 'dumbest' of UPnP/DLNA renderers. I can imagine cutting the stream, even temporarily, could permanently interrupt some (if not all) UPnP renderers, requiring manual/user intervention.

 

No it doesn't it just means end of the track for UPnP Renderer. There's no other way for server to tell the client that the track has ended... It is completely normal for HTTP which UPnP is based on. For example when a web server sends a picture, it just cuts the TCP connection after sending the last byte to indicate end of the file. Sometimes the server can tell the size as part of the headers, but it is optional and not always known (dynamically generated HTML content, internet radio, etc).

[Miska]

Well quite, it's what I meant by the UPnP renderer being 'interrupted'. It just assumes the 'track' has ended and stops playing. The user then has to get involved by reselecting the stream via the renderer's controller app to get it the process going again. Not very user friendly and hence why I imagine the developer fixed the stream's audio resolution to prevent that scenario. Don't forget the 'foobar play capture' stream 'track' is provided by a (public) UPnP media server, so is available to any UPnP control point on the network.

 

In that case usually the control point would tell the renderer to proceed to the next URL. IOW, control point is waiting for the renderer to report that the current track has ended. Then it will take actions to proceed to the next one. Which can also be the same as previous. It is still better than the current situation where the stream anyway cannot be played (because format cannot change on the fly in the middle of WAV).

 

So I don't see any contradiction at all with the normal UPnP behavior.

[Miska]

Or, dare I say it, Miska could 'just' provide the HQPlayer with a UPnP renderer front end and you could use the foo_out_upnp component instead

 

That's called HQPlayer Embedded when combined with Rygel. But there is no need or point to use something like foo_out_upnp with such...

[Miska]

Edit: Just noticed thisI believe the actual situation is that the supplied playback capture stream can continue to be played, regardless of the source sample rate/bit depth changing. The issue it that in order to allow to do so, it's (user configured to) a fixed sample rate/bit depth wav file stream or raw lpcm stream.

 

Yes, and the (optional) change I was proposing would allow the stream parameters to change... With control points that support the "repeat current track" option it would work the same way as with HQPlayer. Even most CD players supported such option...

[Miska]

The real solution is to have hqplayer implement a proper UPnP AV renderer, which will have way more use cases than this one. "Should be relatively easy to implement".

 

As I said earlier, that already exists in form of HQPlayer Embedded, and it works with BubbleUPnP App as you may remember.

 

But that one is not "easy to implement", implementing the UPnP XML messaging in a way that it works with most other implementations is PITA (as you probably know, for example the kind of crap Xbox360 has in it's implementation, etc). And I have no plans or interest to create UPnP support for HQPlayer Desktop. But of course that doesn't mean someone else couldn't do it, because HQPlayer Desktop has open control interface.

[Miska]

sounds as good as hqplayer, and have a good interface...isn't that what people are trying to do here?

Miska should team up with a player that has a good interface.

 

"Good interface" is subjective. To me, HQPlayer has good interface (actually two you can switch between). To me, personally, other interfaces just have extra bells and whistles that get on the way of listening...

 

But in any case, there are already three alternative interfaces that use HQPlayer as a playback engine; Muso, Roon and Alchemy.

[Miska]

To some extent i agree...i don't need streaming lyrics, fancy history of artist, or other players gimmicks...but i would want an interface that functions easily for my purposes. I like to pick random songs for playing without having to create a playlist.

 

You could create such for HQPlayer using the provided control API or the command line control utility... You could even make it embedded into Windows File Explorer context menu.

 

You can add items to the playlist with queue-option flag and then send next-command. This will proceed to the next while removing the current item from the list. This keeps the list one item long.

[Miska]

What about Alchemy - do you know if that is still available somewhere?

 

Yes, there are links to all three on the HQPlayer web page.

 

Regarding the control API, is this just for Linux? I've made a wee C# project which sends commands to hqp-control.exe (inspired by bogi's script), but I can't find com components to interface directly?

 

No, it works on all three platforms, source code for hqp-control is on my web page too.

 

It is just simple XML-over-TCP.