Here. Also the girlish squeals of delight will be a dead giveaway.
Thank you Andrew
This thread has the 3rd biggest number of views on the entire forum after roonspeakers and the roonserver update thread.
Its clearly a very important issue!
Or some very active users? Maybe HQPlayer is a big thing, and an API for other programs to connect to is probably very welcome, but I wouldnât expect Roon to support any(every) other external player. Roon supporting Squeezebox for example, why support something that isnât even supported anymore? There are many devices so it makes a little sense but it is taking it to the edge of expected support: be the big player and let others join usâŚ
How about: be the big player with the best sound and let others join usâŚand that would be Roon playing through HQPlayer IMHO.
FYI- Squeezebox is still supported as open source software, just not by Logitech. There are new versions, etc. still being written.
For those familiar with HQ Player, does it have decent EQ fucntionality? Thatâs the one thing I miss from having used JRiver in the past. Cheers.
Thanks. I think that means I can load a pre-saved EQ fileâŚ
Hereâs a question perhaps someone would be so kind to answer.
Thinking slightly ahead to HQP integration with Roon, if I have my Roon Server (a fully-loaded NUC performing admirably) and a Roon Remote (Mac Mini, basic model with new SSD drive installed and hooked up to my hi-fi via USB / Regen)), which machine do I install HQP on, the Server or the Remote, i.e. do I need the Windows or OS X version of HQP?
In Roon all the audio processing is done in the Core. The audio stream only goes to a Remote if it is sent to a Private Zone connected to the Remote. On that basis I will be getting the Core OS version of HQP. I didnât get HQP after the free trial because I eventually plan to run RoonServer for Linux rather than Server 2012R2.
I think in most cases youâll put HQP on the machine with the Roon core, but thereâs some flexibility here.
When Roon is playing through HQP, it inserts a special âRoonâ item in HQPâs playlist, and then passes a bit-perfect stream to HQP via that playlist item. HQPlayer owns the relationship with any playback hardware. You might be using HQPlayer to play to a local/usb output, or you might use NAA to move the audio stream elsewhere.
When configuring HQPlayer in Roon, youâll type the IP/network address where HQPlayer is running into Roon, so thereâs no requirement that they be on the same machine.
@brian In the example of Roon playing to a RoonSpeaker aware network endpoint or RoonReady hardware; how does HQPlayer know or manage the audio stream in that relationship? In your description, Roon hands off the audio for HQP to render AND deliver to the audio endpoint. Or have I missed something?
Thanks @brian, itâs great to hear details about the integration. Since weâre in Feature Requests Iâm going to suggest that it would be great if Roon could treat HQP in an âeffects loopâ way so that all the zone functionality in Roon can be used. Would it be possible for Roon to incorporate an NAA so that HQP returns the audio to Roon for distribution ?
It doesnât. If youâre streaming HQPlayer, youâre using HQPlayer all the way to the endpoint. Thereâs no loopback into Roon for distribution via other technologies.
Thereâs nothing fundamentally wrong with the idea of a loopback mechanism. Iâd like to see it happen, butâŚ
- The current approach can be implemented without major changes to Roon or HQPlayer.
- The interfaces currently exposed to us by HQPlayer arenât sufficient to do loopback-style processing well.
- The current approach still feels necessary because it preserves the HQPlayer sound by allowing their engine to own as much of the playback process as possible.
NAA does not feel like a good solution for getting the stream back into Roon because itâs designed for playback, not as a DSP plugin interface. Roon needs to know the precise relationship between the concept of âtime in the audio streamâ and âtime on the wall clockââsystems like NAA are almost certainly going to destroy this because they are not built around that set of constraints.
If we were going to do loopback, weâd want an interface in HQPlayer that was built for that purpose: something where it can take a stream, process, and return it to us simply without jury-rigging network protocols built for other purposes.
Iâm hoping that this first round of integration will be a good first step between Roon + HQPlayer, and will establish confidence on both ends about our ability to work together and deliver product. Assuming this works out well, I donât see why we shouldnât want to do more in the future.
I have a PS audio DS with a bridge II, hooked up to the network via RJ45. For this setup I use Jriver in the MacMini, and Jremote in an Ipad.
Would it be possible to have the Macmini acting as the Roon server, together with HQPlayer with NAA, connected thru ethernet to a switch and from there to the DS, instead of using USB, and therefore reproducing the Jriver setup but now with Roon and HQPlayer instead?
HQPlayer accepts lossless stream of music, format like FLAC/ALAC or WAV/AIFF.
Would Roon be able to send MP3 to HQPlayer? I mean, would Roon be able to convert file to an acceptable format for HQPlayer?
I could be wrong, but I donât think the PS Audio DS + Bridge II supports NAA. Thatâs really a question of HQPlayer/NAAâs capabilities. Roonâs role in this integration is getting the audio stream passed to HQPlayer cleanly and providing browsing/control interfaces.
Yes, with Roon + HQPlayer, Roon decodes the file/stream/etc to a PCM/SDM stream and then passes that stream on to HQPlayer, so Roon+HQPlayer will support exactly the same set of formats/configurations that Roon supports by itself.
Good news!