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

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

[Miska]

8 hours ago, bibo01 said:

@stefano_mbp@The Computer Audiophile @Miska I am still unclear about this UPnP business...

Miska, is it fair to say that HQPlayer is somehow at the mercy of Rygel in terms of receiving UPnP commands for rendering?

 

Yes, Rygel is the UPnP stack and controls HQPlayer based on the UPnP commands.

 

8 hours ago, bibo01 said:

If that is the case, there must be some miscommunication between server-controller-Rygel in some particular circumstances that cause delay.

 

That is likely the cause.

 

8 hours ago, bibo01 said:

If, as Simon/MinimServer poited out, the delay is in the Rygel UPnP stack, is it possible to propose solutions to Rygel's main development group (Zeeshan Ali, Jens Georg, Thijs Vermeir, James Henstridge and Jussi Kukkonen) in the GNOME git repository?  (There is a "Jussi" there too )

 

That could be one way. I know Zeeshan and (the other) Jussi personally, they are my ex-colleagues from my Nokia days.

 

Rygel itself was used for example in our N9 phone and was DLNA certified already at that point. (there are many UPnP implementations talking about DLNA, but only few of those have been certified). Note that HQPlayer is not DLNA compliant, as it doesn't support 128 kbps CBR MP3 or WMA which for example are requirements for DLNA.

 

[Miska]

5 hours ago, stefano_mbp said:

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

 

No, this would be OpenHome it is not part of UPnP specification. And how for example HQPDcontrol works with HQPlayer server using HQPlayer's control protocol.

 

But not UPnP AV. In UPnP AV, Control Point holds the playlist and instructs renderer to proceed to the next track when the previous track ends. This is also similar to how Roon uses HQPlayer.

 

The optional extra feature in UPnP AV, SetNextTransportURI allows Control Point to provide upcoming next URI to the Renderer before the current track ends.

 

UPnP Renderer then issues HTTP GET request for the content to the Media Server.

 

5 hours ago, stefano_mbp said:

In other words, Roon operates in "push" mode against HQPlayer while the UPNP renderer operates in "pull" mode against Minimserver.

 

No, both work in the same way.

 

[Miska]

5 hours ago, stefano_mbp said:

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.

 

UPnP Media Server is passive. But UPnP Control Point is active.

 

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.

 

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

[Miska]

12 minutes ago, stefano_mbp said:

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

 

Rygel does support SetNextTransportURI.

 

HQPlayer doesn't implement any UPnP stuff at all. Only Rygel's renderer-interface.

 

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.

 

[bibo01]

2 hours ago, Miska said:

11 hours ago, bibo01 said:

If, as Simon/MinimServer poited out, the delay is in the Rygel UPnP stack, is it possible to propose solutions to Rygel's main development group (Zeeshan Ali, Jens Georg, Thijs Vermeir, James Henstridge and Jussi Kukkonen) in the GNOME git repository?  (There is a "Jussi" there too )

 

That could be one way. I know Zeeshan and (the other) Jussi personally, they are my ex-colleagues from my Nokia days.

 

Rygel itself was used for example in our N9 phone and was DLNA certified already at that point. (there are many UPnP implementations talking about DLNA, but only few of those have been certified). Note that HQPlayer is not DLNA compliant, as it doesn't support 128 kbps CBR MP3 or WMA which for example are requirements for DLNA.

Then...can you please talk to them?! 

[The Computer Audiophile]

Ideally someone like Simon from MinimServer would work with a control point developer like Marcin from JPLAY and come up with a way to send audio to HQP natively. I think both pieces need to be HQP aware. The server needs to speak HQP language and the control point needs to see the HQP server natively rather than through UPnP. 

 

Perhaps I have this wrong, but it would be really great to get something like this working. If Roon did it many years ago, there's obviously value in it. 

[Cebolla]

1 hour ago, The Computer Audiophile said:

Ideally someone like Simon from MinimServer would work with a control point developer like Marcin from JPLAY and come up with a way to send audio to HQP natively. I think both pieces need to be HQP aware. The server needs to speak HQP language and the control point needs to see the HQP server natively rather than through UPnP. 

 

Nothing really anything MinimServer can do as it has no means of knowing what the playlist is and is basically is just an HTTP file server. As the owner & manipulator of the playlist, the workaround should be JPLAY's entire responsibility.

 

 

1 hour ago, The Computer Audiophile said:

Perhaps I have this wrong, but it would be really great to get something like this working. If Roon did it many years ago, there's obviously value in it. 

 

I very much suspect Roon 'works' because it simply sends the output of its Roon Core server's (gapless supporting) internal audio file player, ie, a continuous LPCM or DSD audio stream (with gapless already sorted out by its player) and not the individual audio file tracks themselves (be they already decoded or in their original encoding). That's certainly what Roon does for its Google Cast support in order to get Chromecast devices, which have never supported gapless playback (& likely never will), to appear to play the files without any gaps.

[The Computer Audiophile]

1 minute ago, Cebolla said:

 

Nothing really anything MinimServer can do as it has no means of knowing what the playlist is and is basically is just an HTTP file server. As the owner & manipulator of the playlist, the workaround should be JPlay's entire responsibility.

 

 

 

I very much suspect Roon 'works' because it simply sends the output of its Roon Core server's (gapless supporting) internal audio file player, ie, a continuous LPCM or DSD audio stream (with gapless already sorted out by its player) and not the individual audio file tracks themselves (be they already decoded or in their original encoding). That's certainly what Roon does for its Google Cast support in order to get Chromecast devices, which have never supported gapless playback (& likely never will), to appear to play the files without any gaps.

 

It can't be the sole responsibility of the control point because the control point only tells the server what to send. If I shut off the control point audio still flows to HQP. The server and HQP must speak the same language. As it stands now, Minim just sends audio via UPnP and that has issues. 

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

[The Computer Audiophile]

17 minutes ago, stefano_mbp said:

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?

I’m just searching for solutions. The way Roon works with HQP is flawless. 

[Cebolla]

1 hour ago, The Computer Audiophile said:

 

It can't be the sole responsibility of the control point because the control point only tells the server what to send. If I shut off the control point audio still flows to HQP. The server and HQP must speak the same language. As it stands now, Minim just sends audio via UPnP and that has issues. 

No, the UPnP control point only interrogates the UPnP media server - in order to obtain the URLs for the audio file tracks in its playlist. The control point then provides the UPnP renderer with the URLs. So the UPnP renderer itself asks the UPnP media server to send it the files and that's via HTTP, ie, nothing to do with UPnP.

 

The issue with standard UPnP is that renderer only gets one URL from the control point at a time. If JPlayer 'spoke HQP' as Rygel does (via the MPRIS media player controller interface) it would be able to send HQPe the entire playlist of URLs and still to 'talk UPnP' with Minimserver.

[Cebolla]

1 hour ago, stefano_mbp said:

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.

 

It's all in the timing - HQPe 'tricks' Rygel & therefore the UPnP control point that it has finished playing the file 1 second before it has actually happened.  Presumably the 1s is a compromise between it being long enough time for the next file to start streaming before the current one has finished playing and short enough time for the user not to notice that the file playing is still the same one & not the next one shown on the controller's display.

[Miska]

5 hours ago, bibo01 said:

Then...can you please talk to them?! 

 

About what? That some third party software is not behaving nicely with their software?

[bibo01]

5 hours ago, Miska said:

 

About what? That some third party software is not behaving nicely with their software?

I do not have a technical solution, but given that there is a miscommunication between server-controller-Rygel, I am sure you might have a good idea on what to propose in order to avoid a delay in Rygel's UPnP stack.  

[Miska]

1 hour ago, bibo01 said:

I do not have a technical solution, but given that there is a miscommunication between server-controller-Rygel, I am sure you might have a good idea on what to propose in order to avoid a delay in Rygel's UPnP stack.  

 

Or maybe the problem is in the server / control point implementation, because the problem does not appear with all implementations.

 

For me, this works well enough for playing Tidal. I don't see point in playing local content using UPnP, since HQPlayer has it's own library and control application infrastructure.

 

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

[Miska]

1 hour ago, stefano_mbp said:

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

 

This depends entirely on the control application implementation. With HQPlayer library, control application gets the entire library data and can present it any way it likes. This is also the way HQPlayer Client does it by offering four different views to the same library data.

 

1 hour ago, stefano_mbp said:

- 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

 

This is certainly one gapless problem, because transcoding adds lag to the file delivery. Especially because I think MinimServer calls ffmpeg binary to convert entire file at once when the file is requested, instead of using libavformat/libavcodec to do it as a stream. There is no guarantee how much time it takes to transcode a file. In any case this is potentially one of the core reasons why it is not working.

 

1 hour ago, stefano_mbp said:

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

 

Yeah, I cannot force MinimServer developer to figure out why it's slower than some other servers. Nor Rygel developers either to modify their implementation.

 

[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

[Miska]

9 minutes ago, stefano_mbp said:

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

 

Here's playing tracks on Atom category CPU, from MiniDLNA server running on very old Core i5 NUC, using mConnect Player as UPnP Control Point on my Nokia 8.1 5G phone:

** Message: 12:52:18.319: idle_req
** Message: 12:52:18.409: stop notify
** Message: 12:52:18.564: state -> STOPPED
** Message: 12:52:18.612: state -> STOPPED
** Message: 12:52:18.625: state -> STOPPED
** Message: 12:52:18.647: uri -> http://192.168.71.14:8200/MediaItems/4452.flac
** Message: 12:52:18.740: state -> PLAYING

 

You can see it is less than 500 ms even on this slow CPU while doing PCM upsampling.

 

9 minutes ago, stefano_mbp said:

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

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

 

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.

 

HQPlayer is not limited in the way UPnP is, that clients would present things the way server exposes them.

 

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

[Miska]

13 minutes ago, stefano_mbp said:

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

 

Yes of course if the UPnP Control Point app just presents what the server sends instead of distilling it. Roon and HQPlayer don't operate such way.

 

[Cebolla]

On 10/19/2021 at 12:21 PM, Miska said:

 

Rygel does support SetNextTransportURI.

 

HQPlayer doesn't implement any UPnP stuff at all. Only Rygel's renderer-interface.

 

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.

 

 

Instead of the 1s fixed time, how about allowing the user to set the UPnP end of track time adjustment, say from a range 1s -10s default 1s (assuming you have enough buffer, or can increase the buffer to accommodate, if user unnecessarily selects 10s in quick control point/media server case)?