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

[stefano_mbp]

@The Computer Audiophile hello Chris,

about the paragraph on the UPNP gapless issue

”One issue that may be a showstopper for people is inconsistency of gapless playback. No matter what people say about gapless playback and the control point being what determines whether or not gapless audio works, my research definitively indicates gapless playback depends on the interaction between the control point, server, and renderer. All three matter. This gapless issue isn't unfixable though. Simon from MinimServer asked me to send him some logs because he has an idea about hat may be causing this issue. Hopefully this can be resolved.”

.

Do you have any news from Simon/MinimServer?

I asked him about this issue again and here is his answer:

”In my test environment (RPi3 for server and RPi4 for renderer, 16/44 FLAC files, no transcoding), the great majority of the delay between tracks that causes these gaps is within HQPlayer (specifically, within the Rygel UPnP stack that HQPlayer uses to enable it to act as a UPnP renderer). Because HQPlayer doesn't use the UPnP gapless protocol, any significant delay during track changing breaks gapless playback.
If HQPlayer is running on a faster machine, renderer track-changing delay will be reduced and any server delay will come into play. Increased resolution and/or server-side transcoding will increase server delay.
The only way to make this work correctly in all cases is for HQPlayer to implement the UPnP gapless protocol. This enables the renderer to start streaming the next track before the current track has finished playing.”

 

It clearly seems the … “ball is in Jussi hands” …

Do you think this issue can be solved?

 

[stefano_mbp]

5 minutes ago, The Computer Audiophile said:

Playback doesn’t immediately stop when the app is closed

This is the same behavior of Bubbleupnp and MConnect … isn’t it?

 

Conversely this doesn’t happen with apps like Lumïn, Linn or Kazoo, ie if you kill/swipe off them playback does go on until the reproduction playlist is finished.

In this case I don't understand how one of these apps / control points can affect the behavior of the gapless playback as they are exactly like a remote command.

[stefano_mbp]

3 hours ago, The Computer Audiophile said:

I would also love if some UPnP servers could send audio to HQPlayer natively rather than via UPnP.

The problem is that an UPNP server is passive, it waits for a request from the renderer, otherwise it wouldn't be an upnp server.

[stefano_mbp]

@bibo01 @The Computer Audiophile

… trying to be more clear …

From what I can understand Roon is the server, manages the library and above all the playback of the songs (as do Audirvana and JRiver).
Using the API of HQPlayer Roon sends (so it is the active part) the songs to HQPlayer, in the same way as Audirvana and JRiver if there are UPNP renderers downstream, the difference is that Roon does not use UPNP.
But Roon is and remains the active part of this chain.
In the case of Minimserver, on the other hand, the situation is different:

• Minimserver analyzes the library and compiles an xml file in which each song is related to its own tags and URL
• the chosen control point (be it Lumïn, Linn, Kazoo, MConnect, Bubbleupnp it doesn't matter) asks Minimserver the xml file so that it is possible to select a playback playlist
• this playlist is then sent to the renderer and at this point the control point task ends,
• it is in fact the renderer who “takes the reins of the game” and takes care of asking Minimserver for the songs to be played.

In all this Minimserver is passive, as opposed to Roon who instead we have seen to be active.
In other words, Roon operates in "push" mode against HQPlayer while the UPNP renderer operates in "pull" mode against Minimserver.
Therefore the request to be able to use the HQPlayer API in Minimserver would mean overturning the logic of Minimserver which should become an active part (therefore assume the "push" mode).

[stefano_mbp]

5 minutes ago, Miska said:

When HQPlayer performs GET request to the UPnP Media Server, it assumes to get ~10 seconds worth of audio instantly. If Media Server at this points starts doing something like calling ffmpeg to transcode content or otherwise lags in being able to provide 10 seconds of audio, you may get a gap because HQPlayer runs out of content to play.

I would like to have your comment about Simon Nash answer about this issue:

”In my test environment (RPi3 for server and RPi4 for renderer, 16/44 FLAC files, no transcoding), the great majority of the delay between tracks that causes these gaps is within HQPlayer (specifically, within the Rygel UPnP stack that HQPlayer uses to enable it to act as a UPnP renderer). Because HQPlayer doesn't use the UPnP gapless protocol, any significant delay during track changing breaks gapless playback.
If HQPlayer is running on a faster machine, renderer track-changing delay will be reduced and any server delay will come into play. Increased resolution and/or server-side transcoding will increase server delay.
The only way to make this work correctly in all cases is for HQPlayer to implement the UPnP gapless protocol. This enables the renderer to start streaming the next track before the current track has finished playing.”

[stefano_mbp]

16 minutes ago, The Computer Audiophile said:

Minim just sends audio via UPnP and that has issues. 

The answer is here:

from Simon “Because HQPlayer doesn't use the UPnP gapless protocol, any significant delay during track changing breaks gapless playback.”

And, as Jussi explain “But the way HQPlayer works, if the control point and media server are quick enough, you get gapless playback even without SetNextTransportURI, because there's enough buffer.”

… quick enough … how much? This seems to me … quite casual.

Wouldn’t be enough to implement the UPNP gapless protocol, as Simon says, without searching elsewhere the solution?

[stefano_mbp]

6 hours ago, Miska said:

I don't see point in playing local content using UPnP

... the most important points I see are (... and I'm a bit short-sighted ....):

- I have more than one system and I would like to use only one control-point (Lumin app is perfect)

- with MinimServer I can manage much more metadata than is possible with the HQPe library (see attachment) ... not even Roon is able to manage them correctly as I could try (classical music is a … hard beast)

- browsing library by metadata is much more effective and pleasant with Minimserver

- my library, together with flac and dsf, includes many thousands Alac files incompatible with HQPe, the conversion is not feasible but I can transcode them on the fly to wav with Minimserver

... the correct functioning of the gapless UPNP would solve all these aspects perfectly, would also constitute a more than valid and interesting alternative to Roon, but I see, very sharply, that unfortunately there is no interest in meeting the customer's needs ...
 

[stefano_mbp]

16 minutes ago, Miska said:

This is certainly one gapless problem

Broken gapless occurs even with not transcoded flac as Simon Nash pointed out

16 minutes ago, Miska said:

This depends entirely on the control application implementation. With HQPlayer library

There is no “intelligent browsing” at all available in HQP … trust me

For your reference https://minimserver.com/features.html

[stefano_mbp]

5 minutes ago, Miska said:

Browsing is feature of the control client. Not HQPlayer server. HQPlayer server just provides library data to the client and it is up to client to figure out how to distill "intelligent browsing" from the content metadata.

…  could be true (with many doubts) but at the moment no app is capable of this functionality with HQP.

This functionality is already available instead with Lumïn, Linn, Kazoo, MConnect, Bubbleupnp, Naim, Lightning DS and more using Minimserver as media server, even in LMS and Daphile using Remote Library plugin … 

[stefano_mbp]

13 minutes ago, Mike Rubin said:

can I operate HQPe from a thumb drive

Yes you can.

Go to this page https://www.signalyst.com/embedded-install.html?

and follow the link in the chapter Downloading and configuring bootable image

select the compatible image for your hw and burn it on a usb thumb drive

… it should be this one https://www.signalyst.eu/bins/hqplayerd/images/hqplayer-embedded-4.26.0-x64amd.7z

connect it to your pc and boot from it … done

 

[stefano_mbp]

5 hours ago, Mike Rubin said:

Am I missing something in my setup?

While Audirvana works “as is” with HPQe JRiver needs some more sw to integrate with HQPe.

@Geoffrey Armstrong wrote some time ago the piece of sw needed, as far as I can remember it worked on Windows only, for this reason I didn’t try it as I’m on Mac.

 

I cannot find the thread where he described it but you can try to PM him to obtain some information.

I cannot help you on micro rendu as I don’t have that device, I tried with my SOtM SMS200 Neo and it worked as expected.

[stefano_mbp]

@Mike Rubin hello Mike ... 

you gave me a doubt and I tried JRiver ... it works!
For a correct setting you have to go to
Tools / Options - Media Networks
select Add or Configure DLNA Servers
then in Audio - Format set PCM 16-bit

 

[stefano_mbp]

@Mike Rubin ... Geoffrey's sw was in fact indicated for HQPlayer Desktop

[stefano_mbp]

@Cebolla ... my guardian angel ... I’ll try asap … 

[stefano_mbp]

@Cebolla @Mike Rubin ... this one seems to be the best configuration of the DLNA Server in JRiver as original resolution and bit depth are both preserved

 

then in Audio - Mode: Original (as you can see Format is now greyed out)

 

 

and here two examples while playing

 

16/44.1

 

24/96

[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 … 🤞

[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 

 

[stefano_mbp]

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

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

 

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

[stefano_mbp]

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

[stefano_mbp]

On 10/25/2021 at 8:25 PM, Miska said:

 

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.

 

Just tried setting both

HQPLAYER_RESET_SDM=0

HQPLAYER_STREAM_FREEWHEEL=1

but nothing changes, the very long delay between tracks is still there.

Cannot figure what could be happening on the server side …

I can only say that playing DSD from Minimserver, without any transcoding, to the same endpoint (raspberry/RoPieee XL) with UPNP/DLNA enabled works without issues

 

Setup used:

Lumin app - Minimserver - Bubbleupnpserver - HQPlayerd - NAA/raspberry pi4/RoPieee XL

[stefano_mbp]

@Miska … with those variables set a few clicks and pops are heard when playing PCM -> SDM files

[stefano_mbp]

On 10/25/2021 at 8:25 PM, Miska said:

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

… I looked deeper in my network configuration … I realized the HQPe computer was connected to a 100Mbps branch, moved it to a 1Gbps branch and everything works without any environment variable set !!!

… it seems the issue is now solved, give me some more time to do more in-depth tests but I think everything is working now

[stefano_mbp]

@Miska few clicks, almost imperceptible, were audible playing DSD in bit perfect mode

Setting the variable HQPLAYER_RESET_SDM=0 they are gone and this doesn’t affect PCM -> SDM that is still perfect.

 

…. Lesson learned : everything on a 1Gbps network and variable set …

 

thank you Jussi