Article: Streaming & Local Content Through HQPlayer - A Nice Alternative With The sonicTransporter

[Miska]

2 hours ago, Geoffrey Armstrong said:

Actually, I have tested my sw in the past with embedded and it did work. I just need to point out though that in the most recent version of HQPlayer, Jussi has introduced an encryption feature for communication between HQPlayer and other apps. This is a great feature, which I asked for myself. Unfortunately though, I have not had time to update any of my apps to take advantage of it yet. Because of that, if anyone's trying to use newer versions of HQPlayer with this feature, they probably won't work with HQAV. Perhaps @miska you could just post here from which version HQPlayer incorporates the encryption feature? My sw will only work with versions prior to that.

 

It shouldn't break existing control applications, so it is kind of optional, for now. But recent HQPlayer Client for example requires it to operate.

 

[Miska]

15 hours ago, Miska said:

Technically, it would only need adding a configuration option(s). But on the other hand it is band-aid for something that should work without. I'm just always concerned about number of configuration options, I already get so much complaints about configuration being too complex. At the moment there are three internal parameters that control this behavior.

 

I've added environment variable options to override default buffering values. This way it won't pollute regular settings. It will come out in next release. Three values (no need to set all):

1. HQPLAYER_BUFFER_TIME to set amount of buffer (in ms, must be multiple of 100 ms)
2. HQPLAYER_IDLE_MARGIN to set how much margin there is left before feed is needed (in ms, must be multiple of 100 ms)
3. HQPLAYER_IDLE_TIME to set how long to run idle before stopping

 

You can set these in /etc/default/hqplayerd

 

[stefano_mbp]

6 minutes ago, Miska said:

I've added environment variable options to override default buffering values. This will come out in next release

Wow! This is really interesting! ... I look forward to the next release with curiosity …. and anxiety … 🤞

[Geoffrey Armstrong]

1 hour ago, Miska said:

 

It shouldn't break existing control applications, so it is kind of optional, for now. But recent HQPlayer Client for example requires it to operate.

 

That’s great to know, thanks.

[bibo01]

9 hours ago, Miska said:

 

I've added environment variable options to override default buffering values. This way it won't pollute regular settings. It will come out in next release. Three values (no need to set all):

1. HQPLAYER_BUFFER_TIME to set amount of buffer (in ms, must be multiple of 100 ms)
2. HQPLAYER_IDLE_MARGIN to set how much margin there is left before feed is needed (in ms, must be multiple of 100 ms)
3. HQPLAYER_IDLE_TIME to set how long to run idle before stopping

 

You can set these in /etc/default/hqplayerd

 

Can you please give us some indications on how to modify them - how they relate to each other, what is default value, etc...

[Miska]

42 minutes ago, bibo01 said:

Can you please give us some indications on how to modify them - how they relate to each other, what is default value, etc...

 

Think BUFFER_TIME as size of a whisky container. There's a valve at the bottom to let whisky run out at constant speed. New whisky is added on top. You can also add just water. But liquid should be kept running always. IDLE_MARGIN is threshold line telling how empty the container can run before you must start adding either more whisky or just water, or otherwise you risk running out of liquid.

 

IDLE_TIME tells how long the liquid is kept running when only water is being added, before the output valve is closed because it seems like we are out of whisky and there's only water left.

 

For the sake of clarity we assume the liquid doesn't get mixed when we add water on top. Whisky is music, water is silence.

 

P.S. I have made some fixes and now SetNextTransportURI also seems to work as intended (at least with mConnect Player). Now the track transition time with Tidal streams is less than 100 ms on Atom CPU. New point release coming shortly.

 

[Miska]

1 hour ago, Miska said:

P.S. I have made some fixes and now SetNextTransportURI also seems to work as intended (at least with mConnect Player). Now the track transition time with Tidal streams is less than 100 ms on Atom CPU. New point release coming shortly.

 

There are now Release Candidate HQPlayer OS images of 4.26.1 available for download. This includes both the additional control variables and fixed SetNextTransportURI support (related to Rygel - HQPlayer communication).

 

In mConnect Player, remember to enable "Gapless support" from the menu.

 

If this seems proper, I will make build packages for regular distributions shortly and make a new complete release.

 

[The Computer Audiophile]

24/192 gapless right now with the new version. This is lovely. 

[bibo01]

1 hour ago, The Computer Audiophile said:

24/192 gapless right now with the new version. This is lovely. 

Please, give us some details. Did you work on the variables? How? What controller did you use?

[stefano_mbp]

21 hours ago, Miska said:

/etc/default/hqplayerd

… is that right?

 

Preliminary feedback :

Setup

Lumin app - Bubbleupnpserver - Minimserver (transcoding flac and alac to wav without changing resolution nor bit depth) - NAA/raspberry pi4/RoPieee XL

• PCM to DSD: gapless finally works! Wonderful! I could try from 16/44.1 to 24/192 as input and SDM as output mode and gapless is working flawlessly.
• DSD as Direct SDM and SDM output mode checked (then bit perfect): gapless not working. DSD files served by Minimserver without any transcoding.

I would have liked to modify the additional control variables (to try if it could solve the Direct SDM  DSD issue) but I cannot find 

/etc/default/hqplayerd 

 

[Miska]

2 hours ago, stefano_mbp said:

• DSD as Direct SDM and SDM output mode checked (then bit perfect): gapless not working. DSD files served by Minimserver without any transcoding.

 

This is one area where you would win by using HQPlayer to play your album in album mode instead of playlist mode.

 

When you play through UPnP, HQPlayer doesn't know if subsequent tracks belong together or if they are separate items, so they are assumed to be separate unrelated items.

 

There's a "state reset" processing for unrelated DSD tracks in HQPlayer to reduce amount of pop/click you get when transitioning between tracks. I have now uploaded updated build where you can disable this by setting HQPLAYER_RESET_SDM=0 in /etc/default/hqplayerd. Now you get gapless playback for related DSD tracks, but louder pop/click when transitioning between unrelated tracks. Only solution to this is to play natively from HQPlayer's library.

 

2 hours ago, stefano_mbp said:

I would have liked to modify the additional control variables (to try if it could solve the Direct SDM  DSD issue) but I cannot find 

/etc/default/hqplayerd 

 

That file doesn't exist by default since it would be empty, so you can just create it. systemd will read it on next restart (just reboot your server).

 

[stefano_mbp]

@Miska thanks Jussi, I’ll try and report back

[bibo01]

9 hours ago, Miska said:

This is one area where you would win by using HQPlayer to play your album in album mode instead of playlist mode.

 

When you play through UPnP, HQPlayer doesn't know if subsequent tracks belong together or if they are separate items, so they are assumed to be separate unrelated items.

 

There's a "state reset" processing for unrelated DSD tracks in HQPlayer to reduce amount of pop/click you get when transitioning between tracks. I have now uploaded updated build where you can disable this by setting HQPLAYER_RESET_SDM=0 in /etc/default/hqplayerd. Now you get gapless playback for related DSD tracks, but louder pop/click when transitioning between unrelated tracks. Only solution to this is to play natively from HQPlayer's library.

Would it be possible for the server to send the information in album mode, if that feature was added to the server side? Can album mode be understood by the UPnP chain? 

[Miska]

1 hour ago, bibo01 said:

Would it be possible for the server to send the information in album mode, if that feature was added to the server side? Can album mode be understood by the UPnP chain? 

 

No, it is not part of UPnP specification. But you can naturally switch over from UPnP protocol to HQPlayer's control protocol and then you don't have such limitations. Then you have also OpenHome style capabilities with server-side playlists and much much more.

 

[bibo01]

1 hour ago, Miska said:

No, it is not part of UPnP specification. But you can naturally switch over from UPnP protocol to HQPlayer's control protocol and then you don't have such limitations. Then you have also OpenHome style capabilities with server-side playlists and much much more.

Trying to understand.... Are you saying that it can only be achieved using HQPlayer's control protocol (like Roon) which "mimics" OpenHome style capabilities? Can album mode be achieved with an OpenHome media server like BubbleUPnP server? And is Embedded compatible as OpenHome renderer?

[stefano_mbp]

16 hours ago, Miska said:

I have now uploaded updated build where you can disable this by setting HQPLAYER_RESET_SDM=0 in /etc/default/hqplayerd. Now you get gapless playback for related DSD tracks

… I tried it but it doesn’t make any difference, I suppose this is due to “related tracks” that cannot be understood using UPNP.

I am tempted to try to change the other environment variables but I fear they may have a negative impact on the functioning of the gapless for PCM files which is now perfect. What do you think?

 

[Miska]

4 hours ago, bibo01 said:

Trying to understand.... Are you saying that it can only be achieved using HQPlayer's control protocol (like Roon) which "mimics" OpenHome style capabilities?

 

No, Roon isn't doing that since Roon isn't using HQPlayer's library. Roon operates in a different way with HQPlayer (using HQPlayer's control protocol though).

 

4 hours ago, bibo01 said:

Can album mode be achieved with an OpenHome media server like BubbleUPnP server? And is Embedded compatible as OpenHome renderer?

 

No, it cannot. And no it is not compatible with OpenHome.

 

By design UPnP is split into three parts, media server, control point and renderer. Media server holds the content directory and would understand content relationships. Control point tells renderer what track URLs to play from media server, when it is time to play those. But already control point is lost on the real content relationships, instead it sees abstraction created by the media server. Renderer only sees one meaningless URL at a time.

 

[Miska]

27 minutes ago, stefano_mbp said:

I am tempted to try to change the other environment variables but I fear they may have a negative impact on the functioning of the gapless for PCM files which is now perfect. What do you think?

 

Likely it won't help at all on this matter.

 

[Miska]

OTOH, the way native HQPlayer works is that HQPlayer holds the library. And the player engine. Then control client (HQPlayer Client, HQPDcontrol, HQPWV, etc) can tell HQPlayer to load and play a specific album from the library. Not some list of tracks, but album (album mode). Or alternatively some arbitrary set of tracks from the library (playlist mode). You can also ask HQPlayer to play from alternative sources, such as CD disc, internet streams, analog or digital inputs, USB input...

 

[Cebolla]

On 10/22/2021 at 10:02 PM, Miska said:

Technically, it would only need adding a configuration option(s). But on the other hand it is band-aid for something that should work without. I'm just always concerned about number of configuration options, I already get so much complaints about configuration being too complex. At the moment there are three internal parameters that control this behavior.

 

Looks like this kid is already admiring his band-aid 😀:

On 10/24/2021 at 2:08 AM, The Computer Audiophile said:

24/192 gapless right now with the new version. This is lovely. 

 

[Miska]

9 hours ago, stefano_mbp said:

… I tried it but it doesn’t make any difference, I suppose this is due to “related tracks” that cannot be understood using UPNP.

I am tempted to try to change the other environment variables but I fear they may have a negative impact on the functioning of the gapless for PCM files which is now perfect. What do you think?

 

I just uploaded updated images of 4.26.2 with a fix for one regression, and /etc/default/hqplayerd wasn't enabled in the systemd service-file, so the setting didn't have effect. Please download the updated image and see if it now works.

 

[stefano_mbp]

1 hour ago, Miska said:

Please download the updated image

…. Done

 

playing from local library (usb stick) a DSD album 

• w/o setting the HQPLAYER_RESET_SDM variable there is a very short delay between tracks, sometimes a very soft click can be heard 
• setting HQPLAYER_RESET_SDM=0 gapless is there, no delay nor clicks

playing through UPNP “chain” nothing changes (with or w/o setting HQPLAYER_RESET_SDM=0) , there is a very long delay between tracks, variable from 5 up to 9 seconds …

[Miska]

1 hour ago, stefano_mbp said:

playing through UPNP “chain” nothing changes (with or w/o setting HQPLAYER_RESET_SDM=0) , there is a very long delay between tracks, variable from 5 up to 9 seconds …

 

That is strange, sounds like there is something happening on the path, at the media server side maybe?

 

You could also try setting HQPLAYER_STREAM_FREEWHEEL=1 which will fetch the entire track as quickly as possible. Not great if you are on a limited internet connection, but in local network should be less of an issue, if the network supports QoS properly. Otherwise it may cause drop-outs on NAA.

 

[stefano_mbp]

@Miska I’ll try next Wednesday and report back, thank you

[The Computer Audiophile]

I've run into some playback stoppages, but I don't have anything definitive for troubleshooting or even know if it's something strange going on here.