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.
It has a convolution engine, but no EQ controls as such, feature list here.
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.