Stream to HQPlayer Desktop from foobar2000

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

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

[bogi]

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

 

Miska already proposed in the HQPlayer thread 2 weeks ago:

If foobar just drops the connection and expects re-connect to the same stream on format change, you can help the behavior by clicking to "repeat one" button down from the toolbar. That will play the current item in a loop.

 

That would be elegant solution.

[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

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

[bubbleguuum]

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.

 

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

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

[cat6man]

well, i hope someone out there jumps on this as the foobar/hqplayer desktop solution seems very robust in the time i've had it operating here (about 12 hours).

 

hqplayerd is more complex to set up with Rygel and bubbleupnp but is not as robust in my system as i'm getting stops that require resets, etc.

of course, this could be due to setup errors on my part but a general comparison shows the foobar solution (using android foobar controller) to be reliable and very fast at changing tracks, while the hqplayerd solution is noticeably slower (using bubbleupnp controller on android) when jumping between tracks, even when the sample rate is held constant.

[beerandmusic]

<>>> vlc>foobar>hqplayer...really??

 

when will there be a "one-stop" player that does it all....

 

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.

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

[beerandmusic]

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

 

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.

I think your interface is "almost enough" if it could do that easily without having to jump through hoops. If the way your design will only work is to add a song to the playlist before you can play it, perhaps you could modify the library view so you could right click a song and select send song or album to playlist and begin playing...that and make it so the library view doesn't scroll to the right. I don't know if i am the only one that experiencing that?

If you could fix just those 2 annoyances, then i would buy it...i would like some of the other players gui features, but they aren't necessary, but these 2 annoyances make the program practically useless to me.

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

[blue2]

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

 

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.

 

Hi Miska,

 

I found Muso which has its own forum. It looks very good, exactly what I want and is only 20€ for lifetime ownership. What about Alchemy - do you know if that is still available somewhere?

 

IMHO I wouldn't pay for Roon just to have library management and background info you can get on the web, especially as it's a subscription - how much does the info change from year to year on the Beatles

 

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?

 

Thanks

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

[blue2]

Yes, there are links to all three on the HQPlayer web page. :)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.

 

Thanks, Google isn't much help for these apps. For anyone interested Alchemy is available for 12AUS$. It seems to just have been established this year but it has all the features I'd want including 'preferred setting' option which I put in my own app - so PCM and DSD each have mapped HQPlayer settings. I've found with the 2 DAC's I've used that Auto gets me into trouble, although I plan to try Auto again with my T+A when I eventually get my new i7 6700K music PC.

 

Any users of Alchemy or Muso on here care to share feedback?

[Benoît]

First, thank you Bogi for describing this very interesting method

 

I have 2 questions :

 

- Using this method, I seem to have no volume control in Foobar, only in HQPlayer. Is this normal or am I doing something wrong? Is there a workaround? I'd rather have volume control in Foobar because it's got keyboard shortcuts and I can then use something like a Griffin Powermate

 

- Is this limited to 2 channels? I use channel replication for stereo sources to bi-amp through my 8 channel DAC (Merging Hapi). Channel replication in HQPlayer (using the Matrix) works, but uses 99% CPU in DSD. So I thought I could use instead the "Convert stereo to 4 channels" in Foobar (running on another computer, and in 44.1k), but that seems to have no effect at all. (I do it in Streaming Profile /Audio Processing and HQPlayer is configured for 7.1)

 

If I uncheck the box "Stereo only" under Streaming Profiles, the sound is slowed down, like read at half the speed, very strange (for both stereo source and stereo source supposedly converted to 4 channels). And I still end up with 2 channels out of HQPlayer anyway.

 

Thanks for your help,

Benoit

[bogi]

- Using this method, I seem to have no volume control in Foobar, only in HQPlayer. Is this normal or am I doing something wrong? Is there a workaround? I'd rather have volume control in Foobar because it's got keyboard shortcuts and I can then use something like a Griffin Powermate

It is not possible to control volume via foobar2000. With http streaming it doesn't seem to be possible.

 

- Is this limited to 2 channels? I use channel replication for stereo sources to bi-amp through my 8 channel DAC (Merging Hapi). Channel replication in HQPlayer (using the Matrix) works, but uses 99% CPU in DSD. So I thought I could use instead the "Convert stereo to 4 channels" in Foobar (running on another computer, and in 44.1k), but that seems to have no effect at all. (I do it in Streaming Profile /Audio Processing and HQPlayer is configured for 7.1)

 

foo_upnp in UPnP Renderer mode supports multichannel as you can read here

https://hydrogenaud.io/index.php/topic,93253.msg785057.html#msg785057

But in http streaming mode called 'Playback Stream Capture' it supports only stereo and only default streaming profile.

 

It's probably because the target renderer capabilities are not known with http streaming.

[Benoît]

That answers my questions, thank you Bogi, again.

[mrmovies]

Hi Bogi , I've been reading this topic carefully as I want to use my foobar as a source and my HQplayer for output (similar to what roon HQplayer integration does) . I wanted to ask if anything has changed before using your method , as HQplayer and foobar have recieved some updates since yout last stHQ v104 (4 years!)

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

[Iving]

Here are notes of my results having tried this.

 

I'm a recent, *very appreciative* convert to HQPlayer.
HQPlayer does two things remarkably well:
1. Playback Sound Quality enhancements. [The main thing, after all.]
2. Finding music you want to listen to *provided you have an Albums mindset* (and enjoy or don't mind the visual stimulus of Album Art).

 

I do *not* have an Albums mindset! And I find Album Art an extreme annoyance. I've stated reasons elsewhere.
Most of the music I listen to is just plain history of pop -
diverse tracks standing on the shoulders of giants -
garnered from a variety of Red Book issues/publications -
some mastered better than others.
I am interested in the evolution of music, and my Library is bespoke accordingly.

 

It's not possible to exploit custom flac tags in HQPlayer.
Most frustrating of all, *I cannot browse with ease a selection of tracks - e.g. a playlist - queueing music I want to listen to on any given day or social occasion.*

 

The only (partial) workaround is to create the playlist in foobar2000 first, dropping it onto HQPlayer Desktop.
Then - in HQPlayer Desktop, although Random play is possible as well as consecutive, in either case I cannot change my mind as the day/session proceeds by queuing playlist-constituent tracks in a different order. I can't permit myself the choice, "I'd like to listen to Track G next, followed by Track P, and then Track D and then we'll review ...".
Assuming the playlist is imported as described, in HQPlayer Client Transport View I can find music scanning only Track [Song] Titles far rhs. I can't view Artist or Album (let alone custom fields) for each Track simultaneously. This makes perusing tracks for picking out music to play a great mental effort - I have to "fill in the blanks" from memory. Not always possible - even for me! I am talking here about *recognition* of music from a preferred list - not *recall* whereby I might *having something in mind already* use the Transport facility lhs which permits piecemeal searching Artist provided it is a Folder - or Performer, Composer and Genre provided the flac fields are mapped correctly. In Transport, it may be possible to engineer the order of tracks, but if your playlist is large, shunting tracks up or down to the correct location is a pita, and then the whole thing is foiled anyway if on Random play.
Client Album view has a better search facility since it probes primary flac fields more extensively - but it is less effective than Transport for reviewing music in a preferred list for manipulation. Whilst I could choose an Album very easily (something I seldom do), I would have to go through multiple steps merely to add a track to Playing Now - based on recall not recognition - and then still not be able to queue it along with others in a preferred order.

 

I know there are recommended front ends for HQPlayer. I would not consider Roon in a million years. I don't think muso and/or Alchemy Desktop would be right for me. I may not have run out of options here.

 

Meantime, I wondered whether it might be possible to use foobar2000 (all ambitions here a walk in the park) as a window on HQPlayer as DSP/upsampling engine.

 

I followed the instructions in this thread with little trouble. Thank you @bogi

I had foobar2000 and HQPlayer on the same machine. Streaming 44.1 kHz 16-bit wav to HQPlayer http playlist where HQPlayer upsampled per preference to 176.4 kHz for DAC as is usual in my case when using HQPlayer alone.

 

My two main remarks are:
1. The SQ sacrifice is too great. Playing through foobar2000 sounded good. Perfectly adequate for background playing. But sounded chunkier, solid meaning harder, less finesse. I went back to HQPlayer for serious listening - even bound by constraints on choosing music as described.
2. There is a fairly serious latency. About 5-6 seconds at a guess. A significant negative on the convenience ledger.
So I've abandoned the idea.

 

Adjustment to HQPlayer, ergonomically speaking, has been pretty stiff so far. I realise I am an atypical user. I hope my notes are accurate and fair. I hope, indeed, that they may be helpful for @Miska should Jussi ever want to develop HQPlayer for non-Album music tastes and appreciation. I am no programmer, and wouldn't dare to make suggestions about the required infrastructure. I respect Jussi enormously for his proficiency, his product and his participation here. I hope he doesn't mind me having my constructive say.