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.
This is great news.
I"ve been holding out on HQPlayer since it doesn’t support ALAC and didn’t think it made sense to convert my library to AIFF because of space issues. I couldn’t use FLAC since I still need to play files on the iPhone. Based on the forums, it seemed like ALAC support for HQPlayer was never coming.
Once this is in place, might be time to pull the trigger on lifetime membership.
This is using as-yet un-released versions of Roon + HQPlayer, but things are working pretty well in development.
@brian Many thanks for your reply, so it would seem there are going to be options on where to install HQP.
So I am a little perplexed still. I understand HQP will put some load on the CPU if one opts for the DSD up sampling, which for most I suppose, is the whole attraction with HQP. I am trialling HQP on my MacMini, purely because that is where my direct USB connection to my system is, and it is coping fine with the up sampling of WAV files from my NAS.
I would like to experiment with HQP on my Roon core (the NUC with Roon Server) and I also have an evaluation copy of HQP on that Windows machine. But damn if I can find the NAA usb driver for OS X, I want to stream from the NUC to the MacMini as a test of the NAA streaming. This in advance of the Roon integration and to make sure my network is ‘ready’. As @brian has said, and I guess the general consensus is that HQP should go on the more powerful machine, which is my NUC, I have purposely kept the MacMini very ‘light’ hardware wise, as the intention will be that it will be a Roon Remote with Roonspeakers when that becomes available.
This is pertinent because you have to choose which HQP license you want, Windows or OS X or other. So I am not sure which route to go down, HQP license on Windows NUC (Roon core) or OS X MacMini (Roon Remote).
One final point, it’s quite (nay, very) hard to find simple information on HQP, the main source of information seems to be CA, and that has both very long and very high-brow (technical) threads, which is very off-putting.
I am sure many of you Roonies are contemplating and waiting for the HQP integration, but it would be great to have your thoughts on how you will be going to do it.
I just bought an HQ Player license for OSX/Linux. I’ve been testing the demo for a couple of months and HQ Player doesn’t seem to tax my headless Mac Mini (Late 2012 2.3GHz i7) very heavily (~12% CPU) when upconverting FLAC to DSD128.
My DAC is currently connected via USB to my Mac MIni. I’m planning on buying the Sonore μRendu when it becomes available and inserting it between my DAC and Mac Mini (or possibly a NAS) and relocating my Mac Mini to somewhere other than my equipment rack. Sonore already supports HQ Player NAA Output (Mode #4) and they’ve announced that the μRendu will support Roon (Mode #5), so I’ll be curious to see how the combination works together (I presume Roon–>HQP–>μRendu in Mode #4).
Please excuse my ingorance…
What does NAA stand for?
“Network Audio Adapter” I believe.
Grubby paws eagerly await this update…
well, I cancelled my trial a while back planning to wait until HQ Player integration was complete. But when @brian posted that screen shot i was sold. Just purchased my lifetime membership AND a licence to HQplayer!
Fingers crossed the integration will come through soon.