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

[Cebolla]

The Squeezebox Server (Logitech Media Server) on the sonicTransporter should also make a good Roon alternative & work with HQPe (via the UPnP/DLNA Bridge LMS plugin):

 

 

@Miska also mentioned that someone managed to get HQPe gapless working with it (but gapless would likely not work with MinimServer):

https://audiophilestyle.com/forums/topic/30983-hqplayer-linux-desktop-and-hqplayer-embedded/?do=findComment&comment=1112294

[Cebolla]

LMS's built-in web browser controller, enhanced by the Material Skin and the Music & Artist Information LMS plugins.

[Cebolla]

The iPeng app is supposed to be the go to controller for LMS on iOS - no idea if the Music & Artist Information LMS plugin works with it though, as I only have Android handheld devices.

 

Fortunately, for those of us using Android, the Material Skin plugin's developer has also provided a webview wrapper app for a seamless web browser controller:

https://github.com/CDrummond/lms-material-app/releases

[Cebolla]

12 hours ago, bibo01 said:

Thanks.

I hope @stefano_mbp intervenes in this discussion because he also had a lot of experience in Embedded/MinimServer/gapless, contacting both developers about it and son on...

 

Hopefully it would be more friendly, never mind more informative, than one of their last 'discussions' on the subject:

 

Unless things have changed since @Miska mentioned anything to me on the subject (~ 3 years ago), HQPe implements its own gapless support method for UPnP by sending the notice of the end of current track playing to the UPnP control point about one second before it actually happens:

 

Bear in mind, this is the UPnP mode of operation that doesn't support gapless playback as far as UPnP is concerned, since if the timing of the end of current track playing notification wasn't 'faked' by HQPe, there would be no time to implement gapless playback. HQPe is relying on that ~1s to be enough time for both the UPnP control point (on receiving the end of current track playing notification) to tell HQPe where to fetch the next track from and for at least some of the next track's data to arrive at HQPe following the subsequent request for that next track by HQPe to the UPnP media server. It appears that the MinimServer UPnP media server isn't quick enough. 

 

 

BTW, @bibo01, wasn't it you that mentioned that you were able to get HQPe to play gapless with LMS via the UPnP/DLNA Bridge LMS plugin?

[Cebolla]

1 hour ago, jcbenten said:

I like iPeng on my iPad Pro (1st Gen) much more than any LMS app on my Pixel 2 XL.  I have since switched to iPhone.  Orangesqueeze was ok but always slower to connect than iPeng.

 

Have you also tried the lms_material_app I linked to (& therefore the web browser controller UI provided by the Material Skin 3rd Party LMS plugin) on your Android phone?

 

 

1 hour ago, jcbenten said:

(Something in my system changed and Android control stopped working and the USB out of my Touch stopped working.  Spent a couple of hours resetting and no go.  Currently i have connected the Touch analog outs to my amp...need to check and see if the coax is working.  I do note that the developer of QLMS has not updated in almost 18 months.)

 

QLMS may not need updating if it's still able to install/update the QNAP with the latest official release of LMS. Having said that its developer did recently mention looking at rejigging the way QLMS updates the QNAP with LMS, regarding the nightly development, the nightly stable & the latest official release versions (currently 8.3.0, 8.2.1 and 8.2.0 respectively) - QLMS appears to be updating the QNAP with the (potentially) unstable nightly development version of LMS by default:

https://forums.slimdevices.com/showthread.php?108702-QLogitechMediaServer-for-Qnap-with-QTS-4-2-or-higher-and-x86_64-I686-X86-support-!&p=1031761&viewfull=1#post1031761

[Cebolla]

By the end of the year:

http://jplay.eu/forum/index.php?/topic/3764-jplay-ios-app/#entry56370

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

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

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

[Cebolla]

The foobar2000 player should work with gapless playback support handled by its playback engine and the resulting continuous audio stream output sent via UPnP to HQPe's Rygel UPnP renderer. So similar to how Roon likely sorts out gapless for its (continuous) audio output to HQPlayer, though of course UPnP isn't used there.

 

The Windows version of fb2k requires you install the foo_out_upnp plugin component to provide the UPnP output support (note: not the similarly named older foo_upnp plugin); the Mac version of fb2k, which doesn't currently support plugins, apparently has UPnP output support built-in (can't test as I don't use Macs) with the feature maintained inline with the foo_out_upnp plugin for the Windows version.

 

Output to the selected UPnP renderer is supposed to be bit perfect but LPCM only and you have a choice of it being sent either as raw LPCM or encoded in FLAC or WAV (presumably the same is true for the Mac version).

[Cebolla]

6 hours ago, stefano_mbp said:

then in Audio - Format set PCM 16-bit

 

Did you test if the PCM 24-bit (aka L24) option works? Otherwise, any 24-bit file tracks in the playlist will be bit depth reduced & therefore not bit-perfect. Presumably, leaving the setting as PCM 24-bit for any 16-bit files would be zero padded to construct the L24 stream, so shouldn't be an issue.

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