Jump to content
  • The Computer Audiophile
    The Computer Audiophile

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

     

     

    Many of us have enjoyed HQPlayer's digital signal processing over the years, but have been less than satisfied with the remote control options. Fairly recent remote options named HQPDcontrol v4 and HQPWV (HQPlayer Web Viewer) have made and continue to make great strides. I use both of these options frequently and love to see the developers interacting with the Audiophile Style community to make each product even better. Perhaps some day they'll charge for their apps, and we can all show our appreciation by throwing some money their way. 

     

    Audiophiles who only play local content from a hard drive can certainly use the aforementioned apps and call it a day. HQPlayer will scan their libraries and the remote apps will enable really nice library browsing and song selection. However, many of us also stream from Qobuz and Tidal. To date, there is no way to add a streaming service to HQPlayer or one of the remote applications. What's an audiophile to do? The answer lies in a combination of UPnP/DLNA and HQPLayer Embedded.

     

    Note: Some people will undoubtedly suggest, "just use Roon." Well, that's one option but it presumes that everyone wants to use Roon. That's an incorrect presumption, as no single product offers a solution for every listener. 

     


    Options

     

    There are many ways to accomplish almost everything in HiFi. I tried several potential solutions when researching this article and settled on one that is the easiest, offers support for any issues that may arise, and is a solution I'd actually use every day. I'll attempt to detail both the recommended solution and some of the stuff I tried over the last several weeks. This will enable readers to make their own decisions and understand why I recommend what I recommend and if they wish to tackle some of the hands-on issues with the other solutions. 

     

    Goals

    1. Streaming content from Qobuz, Tidal, and local files from NAS or hard drive through HQPlayer. 
    2. A nice looking and very usable interface for remote control.
    3. Simplicity in setup and daily use. 

     


    Recommended Solution

     

    Playing local content through HQPlayer is a simple task, but to route Qobuz and Tidal through HQP requires a little different setup. Trust me it's very easy and doesn't require jumping though unsupported hoops. The first requirement is using HQPlayer embedded because it can receive audio via UPnP/DLNA as an input. HQPlayer Desktop doesn't have this option and will not work. In order to send audio via UPnP/DLNA to HQPlayer Embedded we need a UPnP/DLNA server and a UPnP/DLNA control point. 

     

    The Small Green Computer sonicTransporter is my recommended solution because it accomplishes the above goals by combining both HQPlayer Embedded and MinimServer as the UPnP/DLNA server into a single component. Rounding out my recommendations is the forthcoming UPnP/DLNA control point application JPLAY for iOS. 

     

    The SGC sonicTransporter starts at $999 and gets reasonably more expensive as one increases processing horsepower, network isolation, and solid state storage. The specific version I used for this article is the $3,499 sonicTransporter i9 Optical with a 4TB SSD. When the Transporter arrived I and installed HQPlayer Embedded and MinimServer with a couple clicks of the mouse. Both are options, among several others, accessed via the web interface. I also copied a few terabytes of music to the internal Transporter SSD, then proceeded to setup HQPlayer and direct MinimServer to the local SSD to scan the music. 

     

     

    sonicTransporter.jpg

     

     

     

    Outputting audio to my DAC was done two different ways. I connected a USB DAC directly to the USB output of the Transporter as a test, to make sure it worked for those who wish to go this route. It worked perfectly. Most of my testing was done using the Sonore signatureRendu SE optical as an HQPlayer NAA endpoint. I connected both the Rendu and Transporter to my network switch via fiber optic cables. I'm not a fan of connecting the Rendu directly to the Transporter via fiber cable because of potential multi-homed network issues, but I know many audiophiles who set it up via direct connection and love it. No judgement here, I just prefer one way over the other. 

     

    Other than the standard HQPlayer setup, selecting filters and an output device, nothing needs to be done with respect to selecting an input. HQPlayer Embedded automatically advertises itself as a UPnP/DLNA renderer and accepts audio via UPnP/DLNA whenever it's sent. The only thing to do once HQPe and MinimServer are setup is to select a UPnP/DLNA control point. 

     

    JPLAY for iOS is easily the best control point app I've used to date. JPLAY for iOS combines Qobuz, Tidal, and local content in a single interface in addition to offering excellent features such as album info and artist bios, links within the app to other content from each artist, record label filters (think displaying only ECM content etc...), among many others I've yet to discover on my own. Searching each streaming service and local content can be done individually or combined into a single search. The user interface is beautiful and very easy to use. One of the extremely audiophile features in this app is the ability to adjust what's called polling time. This can be set to a maximum level, so once albums/tracks are selected for playback, the app is completely silent. It doesn't send any network traffic to the server or renderer. 

     

    JPLAY iOS App 01.jpg

     

    JPLAY iOS App 02.jpg JPLAY iOS App 04.jpg JPLAY iOS App 06.jpg

     

    JPLAY iOS App 07.jpg JPLAY iOS App 03.jpg JPLAY iOS App 05.jpg

     

     

     

    This combination of HQPlayer Embedded & MinimServer on the sonicTransporter and JPLAY for iOS on my iPad Pro is fantastic. There are certainly some issues to be worked out in the JPLAY control point app, but it's still in closed beta. Using the JPLAY app on iOS to send audio to other renderers in my system was flawless. For example, I set an opticalRendu into DLNA mode and used the same MinimServer install on the sonicTransporter with great success. I think the little issues revolve around HQPlayer Embedded's use of Rygel as the UPnP/DLNA rendering software and its interaction with the JPLAY for iOS app. 

     

    As a temporary solution, until JPLAY for iOS is released, listeners can use the mconnect app as a control point. I don't wish this on my worst enemy, but many people use it and are OK with it. Some people use one of the HQP apps such as HQPDcontrol v4 or HQPWV for local content, then switch to mconnect for streaming audio only. This is an option, but it seems so primitive. Like something we'd do in 1998 :~)

     


    Possible Showstopper

     

    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. 

     


    Bits and Bytes I Tried

     

    The gapless issue mentioned above is what caused me the most headaches. Not because I listen to a ton of music that requires gapless playback, but because I wanted to find a solution to the issue. Here are some of the solutions I tried and what I found. 

     

    I installed Ubuntu 20.04 on my CAPS Twenty computer, then installed HQPlayer Embedded and MinimSever manually. This enabled me to connect to the server and test many things via command line. No matter what I did, I couldn't get gapless working with HQPe and MinimServer on this install either. I also put HQP OS on this machine and Minim on my NAS, but the results were the same. 

     

    One benefit of running Ubuntu 20.04, with a manual install of the apps, is that I could install the NVIDIA drivers for CUDA offload within HQP. 

     

    On my Ubuntu 20.04 installation I also tried Asset UPnP and MiniDLNA as UPnP/DLNA servers. I couldn't connect to Asset via the JPLAY iOS app, but was able to get with mconnect. Gapless didn't work with Asset and HQPe whether on the same machine or split with Asset running on my NAS. Surprisingly, MiniDLNA worked every time. Yes gapless audio from MiniDLNA (version 1.3 with DSD enabled), sending the audio to HQPe and JPLAY as the control point worked great. However, MiniDLNA server was terrible on all other respects such as speed, album art, search, etc... I suggest this solution only to the most hardcore gapless fans. 

     

    Another interesting solution was using the built-in QNAP DLNA server. This surprised me even more than MiniDLNA because it was also gapless. Using JPLAY on iOS to select audio on my QNAP NAS running the built-in Multimedia Console and streaming add-on, and sending it to HQPe, worked every time. Unfortunately, I don't even recommend this as a solution for gapless freaks. The usability with any control app I tried was horrific. 

     

    Attempting to outsmart myself, I installed BubbleUPnP on the sonicTransporter (it's one of the easily installable options), because Bubble makes a UPnP/DLNA renderer into an OpenHome renderer. I thought this may be the solution to my gapless issue and be an awesome all-in-one (HQPe, MinimSever, BubbleUPnP all on the sonicTransporter). Nope. No gapless in this configuration either. One nice part about this was that I could test the Lumin and Linn Kazoo apps for control, but neither of them gave me gapless either. 

     


    Wrap Up

    Running both streaming and local content through HQPlayer using UPnP/DNA as an alternative to Roon is definitely doable. I've been doing it for weeks and really like it. The easiest and best way to do this for most audiophiles is to use a Small Green Computer sonicTransporter. The Transporter can house both MinimServer and HQPlayer Embedded on a single box, and SGC can provide support if people run into issues along the way. I've known SCG's founder Andrew Gillis for many years and can attest to his knowledge, skills, and customer service. He knows what he is doing and works hard to make sure his customers are satisfied. 

     

    I'll send back the sonicTransporter i9 Optical in the next day or so because the last thing I need around here is another server. If I didn't have CAPS Twenty, I'd buy the transporter in a heartbeat. The i9 ran HQPlayer upsampling to DSD256 using poly sync short MP filters, the ASDM7EC modulator, and 65,000 tap convolution filters without a hiccup. This little machine is much more powerful than it appears and it looks much better in person than in photos. 

     

    Given that I have CPS Twenty, I am running HQP OS on the NVMe drive, MinimServer 2 on my QNAP NAS, and the JPLAY iOS control point on my iPad Pro. This is a slick solution. I can update HQP OS by booting from the other NVMe into Windows, and using Balena Etcher to write the latest version of HQP OS to the HQP OS NVMe drive. Then I reboot and I'm all good. 

     

    I highly recommend the sonicTransporter for everyone who has no interest in installing an operating system or writing an image to a USB/SSD drive.  The transporter is just so simple and works so well. It's a no-brainer. 


     

     

     

    More info:

    sonicTransporter

    HQPlayer

    MinimServer

    JPLAY

     

     

     




    User Feedback

    Recommended Comments



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

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

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

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

    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?! B|

    Share this comment


    Link to comment
    Share on other sites

    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. 

    Share this comment


    Link to comment
    Share on other sites

    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.

    Share this comment


    Link to comment
    Share on other sites

    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. 

    Share this comment


    Link to comment
    Share on other sites

    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?

    Share this comment


    Link to comment
    Share on other sites

    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. 

    Share this comment


    Link to comment
    Share on other sites

    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.

    Share this comment


    Link to comment
    Share on other sites

    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.

    Share this comment


    Link to comment
    Share on other sites

    5 hours ago, bibo01 said:

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

     

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

    Share this comment


    Link to comment
    Share on other sites

    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.  

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

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

    4A69DD3C-B472-498F-AF83-3EAC89C1BA29.jpeg

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

    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

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

    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 … 

    Share this comment


    Link to comment
    Share on other sites

    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.

     

    Share this comment


    Link to comment
    Share on other sites

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

    Share this comment


    Link to comment
    Share on other sites

    As long as we are discussing UPnP, I don't know how others feel about this, but I would love to use JRiver as my control application and library manager because I find it much more flexible than the HQPlayer client.  (I am aware there is an experimental workaround that is supposed to allow this but I never got anything to play even after following directions explicitly.)   Frankly, while it is fashionable to bash JRiver, if it sounded as good as HQPlayer does on most material and had better DSP streaming skills, I wouldn't need anything else.

     

    It doesn't sound as though UPnP integration is something we can expect from HQPlayer, but, if it were to be implemented and work reliably, I would upgrade from Desktop Embedded to have access to it.

    Share this comment


    Link to comment
    Share on other sites




    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now




×
×
  • Create New...