Stream to HQPlayer Desktop from foobar2000

[Cebolla]

Aren't you always going to have an issue with a fixed sample rate & bit depth, if all you are doing is providing HQPlayer with just one pcm stream to 'funnel' the whole of the music file playlist?

 

May be you should be concentrate instead on providing HQPlayer with a 'proper' UPnP renderer front end, which can trap separate track stream URLs from the instructions from UPnP control points and forward those streams to HQPlayer.

[Cebolla]

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.

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.

 

The other foobar2000 UPnP supporting plugin component, foo_out_upnp, does change the stream settings to follow a new sample rate change, but it also changes the URL for the new stream. However, it can only do this because it also employs a (user hidden) UPnP control point to instruct the UPnP renderer as necessary.

[Cebolla]

Thanks Miska, I sent bubbleguuum your proposal via PM on hydrogenaudio.

If he would agree to implement it, the benefit would be retained simplicity of this solution. The foo_upnp plugin installation and configuration is for this purpose very simple and no other SW is needed.

 

I will let you know his answer.

Bubbleguuum has been known to use these forums, even converse with Miska! May be you could get him to respond here?

[Cebolla]

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.

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.

 

Which is why I also mentioned the other foobar2000 UPnP plugin (not Bubbleguuum's) whose http server (not exposed as a UPnP media server) does send varying sample rate streams, but also directs the UPnP renderer to the appropriate stream with its built-in UPnP control point.

[Cebolla]

Now 'Playback stream capture' in foo_upnp contains bitrate combo box, where user can select desired fixed bitrate. I could imagine a solution, which would retain the current fixed bitrate functionality, but one special entry would be added into the combobox, it could be called 'adaptive' or 'variable' ...

 

That could be done automatically based on currently played source content, when that 'adaptive' bitrate choice would be selected.

 

What I suggested would be in effect only if 'Playback stream capture' is used (that's already a special case how to use foo_upnp) with 'adaptive' bitrate mode set. Otherwise the adaptive bitrate behavior wouldn't be in function and all would function as till now.

Yes, it certainly makes sense to just extend the current functionality to include the 'adaptive/variable' mechanism as an option.

 

Depending on the control point being used, user intervention could simply be to switch on the 'repeat track' or 'repeat playlist' function on the UPnP control point if it has one. So no need to manually press play again.

However, in the absence of a repeat function, it would be a bit more complicated. The user would have to create a playlist containing just the same playback stream capture 'track', the number of tracks depending on the times the stream is going to be cut. Probably not such an issue if the contol point has the ability to create & save playlist with a very large random number of the same track, which can simply be reused.

 

Ultimately, the original function will need to stay in place simply to account for the any of the above not being possible for the user to do with the control point(s) that is/are available and the user not wanting to have to manually press play again if the stream is cut.

[Cebolla]

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.

 

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

Yes, no contradiction with normal UPnP device behaviour, but you are likely asking the device user to change normal behaviour.

 

Worst case, the user's setup could be the 'two box' scenario, one box being the UPnP/DLNA media server, the other box being the control point combined with the network music file player (some older DVD/BD players, AVRs, TVs, etc) and no option to use a (3rd party) UPnP control point. Very many of these combined control point players, only provide the user with a crude top down hierarchical folder access to the UPnP/DLNA media server, with no ability to build a random playlist of tracks, let alone be provided with a repeat track/playlist function. So the user would have no option but to manually press play again if the stream is cut.

 

 

Edit: Just noticed this

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).

I 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.

[Cebolla]

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

[Cebolla]

I hope your careful reading noted the importance, regarding any possible future change, of this post by @bubbleguuum developer of the old foo_UPnP foobar2000 plugin component (central to Bogi's method) and the response by @Miska developer of HQPlayer:

 

On 9/14/2016 at 11:05 AM, bubbleguuum said:

 

I now vaguely understand your proposal. foo_upnp closes the http stream on samplerate/bitdepth changes and hqplayer is setup to reconnect to the same URL, streaming a WAV stream in the new samplerate/bitdepth format.

I do not work on foo_upnp anymore since a while, so no plan to implement that behaviour. And even if I did, it supposes a player that reconnect to the current stream on playback failure (or set on 'repeat track').

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".

 

On 9/14/2016 at 8:20 PM, Miska said:

 

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.

 

The foo_upnp plugin has certainly never been updated at all since (still at version 0.99.49) and as far as I'm aware, HQPlayer Desktop (ie, not the Embedded version) was never updated to implement a UPnP renderer. So don't expect any major change.