HQPlayer / Roon Integration: Ready for Prime Time?

Recently read through all positive posts about HQ Player, and noticed that many in the Roon community have been clamoring for HQ Player integration for months. This recently caught my eye.

After purchasing it, I quickly discovered these limitations:

1/ HQ Player is a seperate process from Roon, e.g., a network end point. This means audio buffers are needlessly copied between Roon output and HQPlayer input FIFOs adding unecessary latency. HQPlayer should ideally be a shared library (plugin) which is loaded into the Roon process.

2/ HQ Player, and probably Roon as well, does overly conservative buffering to avoid network drop outs. This, in addition to extra out-of-process buffer copying, bumps up the latency (I experience +5 seconds). This latency is so high, that you can only just barely use the transport controls in Roon. There should be a bi-directional throttling/QOS protocol which dynamically adjusts FIFO depth in both apps - it can’t be a static, high value.

3/ HQ Player doesn’t appear to run headless (at least I haven’t figured out how to do this yet). This means you have two Player UI applications up. Let’s just say, generously, that the UI’s don’t look like they were designed in the same century.

4/ Roon looses track of the internall state of HQ Player way too easily. There are probably multiple issues with both apps that need fixing here, but HQ Player should export an API to Roon that let’s it “query” the state of the player dynamically -and/or- there should be an async notification sent from HQ Player to Roon whenever its state is updated. For instance, you can simply bring up the preferences in HQ Player during playback (without saving or changing anything) and Roon will assume the worst and drop the connection.

5/ Roon apparently can get various properties from HQ (SR, filter alg, …), but it would be nice to be able to select the dither + filter alg and other parameters without having to step into HQ.

6/ iOS iPad app doesn’t know about HQ Player properties yet, but I’m sure that is just waiting for Apple app stiore approval.

In short, I really wanted this to work out, but I am disappointed enough to post this here. I really bought into the hype on the forums regarding HQ Player, so Its easy to get swept away by the descriptions from fellow audiophiles claming NS5 dithering makes all the difference in the world. :wink: Personally, I was hoping I could run convolution IR room correction with Roon using HQ, but I can only speculate on the additional latency impact there. To its credit, Roon Labs responded to a great deal user pressure - that speaks highly of them - thanks for listening - but what we have currently is a very minimal , “let’s get the monkey off our back”, kind of solution which is really not in spirit with the polish in rest of the app. This is an intriguing “proof of concept” implementation.



My thoughts exactly, and you expressed it eloquently.


Well put. I agree with the clunkyness. At the same time though, for me, it sounds good! Which means i will put up with it for a while, giving some time to hqplayer and roon to make it nit only a well sounding solution but also a smooth one.

I’m not going to use another piece of software to run on top of Roon. For me Roon sounds fine on its own. :grinning:
Is it not the goal of Roon to be the best music software out there?? Well then they should have a menu where the user can select these settings…not depend on other software to do it.
I’ve paid enough for this program and feel it’s upto them to give these type of filters and other settings



I somehow need to agree with stevev1. While I appreciate complex tweeking of music processing which is an endless process and one of my hobbies, I don’t think Roon was designed for this. Roon is a beautiful, out-of-the-box, extremely well designed software that plays excellent music without any effort needed from the user. And I love it that way, I am just… enjoying my music (plus this is the first music software that my wife happily uses as well). Now I also like to play with HQ player from time to time, but I do this along with other softwares such as JRiver, or even better in the sense that EVERYTHING can be modified, Foobar2000.
Although please don’t misunderstand me, Roon needs to be congratulated on the effort they put in making users happy, lots of people asked for HQ player integration, and there you go, it got somehow integrated. But glitches will be there still, because these are 2 pieces of software that were indeed designed in different centuries, or at least with completely different philosophies, so don’t expect full, glitch-free integration to happen soon.


Well… It’s marked ‘BETA’ (red, capitalized) for a reason, I guess.

There’s a lot to like about HQ Player, but, as @andybob so eloquently laid out, it is not for everybody. Its core competence (taking care of all DSP with superior filtering, dithering and upsampling) to compensate for (and surpass) the weak DSP present in most DACs is a very strong asset, but if you’re happy with your current DAC and setup, there’s really no obligation. :wink:

While current hiccups will be straightened out (on both sides), I would not get my hopes up for a fuller integration anytime soon – it’s way too much of a niche product for that, and I would guess it is slightly more involved than a shared library or plugin.

Upsampling to DSD takes some serious computing power – most of the delays are present in HQP locally as well. I find that when upsampling in PCM, most control delays in Roon are <1 sec., so network latency / buffering is not really an issue.

For me, the fact HQP integration turned a measly Pi-based NAA into a superior alternative to my Meridian MS600 is amazing and valuable. As filters go: after some careful listening, it is more or less ‘set and forget’. Whenever a more adventurous mood strikes, I just remote in from my iPad and filter my heart out.

But hey – YMMV. Enjoy the music!


I guess a version 1 of anything is always going to leave room for improvement…

HQPlayer wasn’t high on my list, and initially I don’t think the Roon team’s either, but hats off to them for acknowledging the huge level of interest and getting a working solution out there pretty quickly.

While I hope they improve it further over time, I can honestly say that I hope all their resources don’t get taken up with HQPlayer development to the detriment of the main Roon product development.

I can’t think of any other recent software product where the developers went from user feedback to a working solution - one that wasn’t even on their roadmap - in such a short space of time. Hard to fault really. IMO.


Some notes in relation to some of Craig’s points:

  • Embedded HQPlayer for Linux runs headless and can be configured through Rygel. It requires Minimserver and BubbleUPnP. Signalyst notes that “HQPlayer Embedded is totally unsupported extra, provided as-is, for users of HQPlayer Desktop for Linux”. If you are currently running HQ Player under Windows then you will need a second OSX/Linux licence to run Embedded HQP. I have not tried Embedded HQP and have no personal experience of it.

  • The particular disconnect upon bringing up HQP settings is all HQP, not Roon. When settings is invoked, HQP tears down the existing state and rebuilds it entirely upon save or cancel. This happens in stand-alone HQP and integration with Roon didn’t change that.

  • Since implementing an NAA I have not had an actual disconnection and Radio is working as intended. I do hear an occasional soft crackle (which may have other causes, I’m also trying out a battery to power the Raspberry Pi).

Having said that, the criticisms of latency, buffering, disconnections and general clunkiness of using two programs are all well made. I know @brian is not happy with the disconnections and has provided the volume control link disconnect as a workaround to avoid restarting either program while he investigates further.

To me the integration with HQ Player is a bit like the case of the talking dog. What it says is sort of less important than the fact it happened at all. Audio designers are notoriously prickly about their respective solutions and there has been some serious co-operation and trust shown on both sides of this project.

So I’m content to take what we have (I purchased HQP licences) and hope for future improvements. Eventually I would love to be able to send an audio stream to HQP from Roon, make some configurations within Roon and have the resulting stream distributed by Roon (including by RAAT). That has been described as treating HQP as an “effects loop” or DSP package. I asked Jussi about that possibility in a thread on CA. While not ruling it out he was concerned at the possible risk to sound quality of that approach.

So apart from the hunting down of disconnection issues on the Roon side, I suspect that further integration will hasten slowly. I think there is little risk of it overshadowing other long planned developments in Roon (eg: RoonSpeakers and improved metadata handling).

I don’t share @stevev1’s expectation that Roon should provide the HQ Player filters “out of the box”. Separate development of similar filters would be a huge undertaking and diversion of resources. There is a reason Jussi has few competitors in this space. Absorbing the cost of providing Signalyst’s proprietary filters would be unworkable. Making HQP available to those interested enough to pay for a licence is the correct approach in my opinion.


There’s a free trial period, if you don’t like it, you don’t buy it! Very simple… :smile:


I love Roon and HQPlayer but at the moment defo as seperate programs.

Much prefer Roon on its own or through my prefered method of squeezelite (picoreplayer) on the Rpi.

Absolutely Jussi. I made a personal choice to purchase HQPlayer based on feedback alone + the aggressive errata/feature update list of both products. That’s on me.

But I did not anticipate such a minimal “two apps running side by side which get out of sync” kind of solution given all the good press your DSP receives. This took my by surprise.


A lot of interesting points Andrew, thanks. A couple of comments:

Embedded HQPlayer for Linux runs headless and can be configured through Rygel.

Yes, I did see this - should this have been version used as the starting point for integration into Roon ? Rather ominously, Signalyst basically says “you are on your own” if you try to use it.

The particular disconnect upon bringing up HQP settings is all HQP, not Roon.

Yes, but I would venture that if the state changed in HQP (by whatever means), that delta-state could be sent “up stream” to Roon which might then decide what to do with that information. Roon could, for instance, halt playback, flush its pipeline, and then prime/restart playback using the new properties HQP has just handed it (which may include sample rate changes, bit-depth, …). All of this can be handled dynamically (and gracefully !) with enough work - it just takes programmer effort to discover and work through the edge cases. An even simpler solution might be to lock out the HQP UI altogether, allow state changes from Roon - only (that’s basically the headless solution).

Audio designers are notoriously prickly about their respective solutions and there has been some serious co-operation and trust shown on both sides of this project.

Indeed, and I certainly don’t want to discourage that. Just hoping my prickliness might just be enough to spark a few (obviously needed) fixes :wink:

That has been described as treating HQP as an “effects loop” or DSP package. I asked Jussi about that possibility in a thread on CA. While not ruling it out he was concerned at the possible risk to sound quality of that approach.

Thanks for the pointer. I agree, that would be an ideal solution: HQP is wrapped up as a VST or AU and Roon becomes a VST/AU “effect” host. Will this be a risk of sound quality ? That’s way too broad and generic a statement for Miska to make - there are too many good counter examples (e.g., all the high-quality plugins hosted by modern DAWs).

I don’t share @stevev1’s expectation that Roon should provide the HQ Player filters “out of the box”. Separate development of similar filters would be a huge undertaking and diversion of resources. There is a reason Jussi has few competitors in this space. Absorbing the cost of providing Signalyst’s proprietary filters would be unworkable.

Yeah, I wouldn’t want Roon to stop innovating on the app/UI side of things at the expense of offering 20 new dithering algorithms, but what is interesting is that the two companies do have complementary expertise (DSP vs App/service design). Code licensing opportunity ? Alternatively, if Roon provided an open plugin/effect hosting interface - no special arrangements would need to be made - 3rd party developers would innovate for the Roon platform independently.


1 Like

That already happens…

First of all, VST and AU don’t understand anything about DSD at all… They are hardwired to their own model, completely around PCM concept. HQPlayer can take PCM or DSD in and output PCM or DSD from it, at different rate, word length, sample type and channel layout. Neither VST nor AU can accommodate such. VST plugin cannot even change sample rate…

Those are not really cross-platform systems either. HQPlayer supports Windows, OS X and Linux. Linux being my primary development platform.

I have my own opinion about quality of most of the DAW stuff… And it is not pretty.

With Pyramix or Sonoma workstation doing DSD production I believe you need to stay pretty well constrained within the DAW’s own infra if you don’t want to compromise the result.

But overall HQPlayer wants to know

  1. Source content format properties
  2. Properties of the output device
    Plugin infra systems generally want to precisely hide these and instead generalize things.


Is there a way for you to licence code to Roon and let HQPlayer DSP become one of the settings page in Roon? Users can pay extra to unlock this settings page, like how Roon users can use tidal in Roon.


Don’t agree with all the OP’s points. The two programs work well for me, without large delays, etc.I don’t have a problem using the controls in Roon while playback is by HQP - it seems to work fine for me. I’m running RoonServer (headless) and HQP on my server. I’ve monitored server temperature and CPU load while running just HQP and compared it to the state when both programs are running on my server and I’m using the Roon as an interface only from another device. No significant difference in temperature or CPU load on the server from running HQP by itself. So what’s the big problem people have with keeping both programs open?

I do have some instances of disconnect between the 2 programs. I assume that will get straightened out over time.

Roon is for playback and a lovely UI. The thrust of HQP is SQ and user control of upsampling and filtering, and choosing the combination that sounds best. Jussi is pretty much an expert at the DSP/filtering side, I seriously doubt anyone at Roon would be able to compete with his level of expertise and experience. But HQP doesn’t have much of a UI.

So, the “marriage” between the two is fantastic. We get the wonderful GUI of Roon and the SQ abilities of HQP. I think together they are the best solution out there for computer audio. My understanding is that to truly integrate HQP into Roon would be a major undertaking, and not something either side is very interested in. I think they have good reasons for that.

BTW, final note to the OP: HQP integration with your Apple device won’t happen till the next version of the iOS app is released.


I see, and yet Roon still decides to drop you as an end point ? Sounds like the fix might be outside of HQPlatyer then.

Well this is a new format, and existing api’s/OS’s need to catch up - it isn’t native (yet). Did Steinberg or Apple anticipate DoD ? No, but, DSD designers did anticipated working well within existing PCM frameworks. I don’t see why a VST or AU plugin couldn’t parse the high order mark/sync byte used by the DoP PCM embedding.

How about being a good citizen and use GStreamer then ? Otherwise, accept the pain of supporting different plugin formats (like everyone else).

I understand your point that a “closed system” can be made optimal more easily, but the flip side is that a closed system can easily lend itself to awkward solutions when they integrate with other applications. Is that not what we have here ?

In any event, I understand all of this is a lot of work to do right. Cheers.

Steinberg yes, ASIO has got native DSD support for ages. VST not. DoP is really an ugly band-aid for inflexible frameworks.

DoP is really sensitive as anything that expects the samples to represent PCM and do any operations on those such way will destroy the DoP container and you get white noise as a result. Using DoP between software components would be also unnecessary extra overhead for doing packing and unpacking between every step.

I’m not going to do that kind of compromises, so I don’t go anywhere near VST or AU until the frameworks are modified to be properly optimized for the usage.

Because it is not useful for me at all, it has the same issues as all other plugin systems. LADSPA is the plugin system on Linux that is closer to VST.

With HQPlayer Embedded I’m providing standard solution, which is MPRIS API:
That is most suitable of the standards for interfacing with my player engine in a headless way.

The control API for HQPlayer Desktop is designed such way that the GUI in HQPlayer stays in sync. There is similar internal interface model towards the Full Screen mode GUI. It is actually also possible for third party to implement their own Full Screen mode GUI, without requiring rebuild or modification of HQPlayer.

Many times when I get complains (IOW, not enough eye candy) about HQPlayer GUI, people have not even tried the full-screen mode GUI (that you can make truly full-screen by checking the box in Settings/Preferences dialog).

Good thing doing my own software is that I get to decide what I do and how. I don’t need to accept pain anywhere where I think it would require compromises that would potentially affect performance and/or quality.

If I start accepting compromises, I’m pretty sure that sooner or later the performance (CPU load) becomes issue and also sound quality would begin to suffer.

Doing DSP on something like 96 kHz PCM is hardly even generating CPU load, compared to doing DSP on something like multichannel 11.3 MHz DSD256.

P.S. HQPlayer is not trying to be like every other player, and not trying to do things like everyone else. It is doing things exactly the way I see best for performance and sound quality. There are many cases where I don’t agree with “everyone else”. :smile:

Bravo, well said!

I’m with you. Especially now that Roon provides a great UI for anyone using HQP.
As soon as a few of the rough spots in the integration get worked out, the Roon/HQP pairing will be the best playback solution on the market (best UI, best sound) - maybe it already is.

The full Roon/HQPlayer integration does require a meaningful commitment of learning time to achieve its full benefits. It has taken me several weeks to get there and I would recommend the following as a way to make sure it is right for you:

  1. Install HQP on a standalone basis and get to know which filters and settings work best for you and which don’t overtax your computing system (I spent more than a week just on this).

  2. Then integrate Roon and run HQP with Roon as the front end making sure everything works (single day works fine for this).

  3. Add the NAA (network audio appliance) and run a headless front end into your DAC. This assumes your music library is on a NAS and it assumes you don’t want a powerful computer in your listening room and you will benefit from separation between the processing computer and the NAA. This part took me more than a week to get to work correctly and caused me to upgrade my network to Cat7 wiring and a gigabit Ethernet switch. I’m using a battery powered MacBook for this now but I’m thinking of replacing that with a Sonore Sonicorbiter SE and linear power supply for it and my Regen.

  4. Add an iPad or Android front end to control the system with Roon as the interface (you don’t even know HQP is there once you have your settings right).

  5. Maybe I should have started with this, but I get the best results from converting everything to DSD256 which requires a DSD256 capable DAC and a computer powerful enough to handle the processing load. This part forced me to up the RAM capacity on my i7 to 12GB.

That is a lot of work and learning, but in my highly resolving system (Magnepan 20.1s), the result is just stunning.