is there no chance that this restricition will be lifted in the future?
i assume it should be technically possible to do so. for example basically like this:
roon passes the audio data to hqp, hqp processes the audio and gives it back to roon, roon puts the processed audio into the roonspeakers protocol, etc
From our perspective, that would be the best of both worlds: HQP does the processing that only it can do, and we take care of the hardware vendor relationships, audio distribution mechanism, and user experience.
I don’t think there are any technical impossibilities here. If HQPlayer provided the interfaces to allow for it, we would support it.
Sounds quite good.
So do you think HQP (Jussi Laako) will allow this?
I think it would make sense also from a business point of view.
I have no idea 
I agree with you @MySound and after it became apparent that the proposed implementation with HQP would result in output through HQP I approached @jussi_laako on the CA forums and suggested that a “DSP” style version of HQP where output was looped back to Roon (or any other player) might open up a new market.
Jussi did not rule out the possibility, but noted that it could have an effect on SQ compared with the NAA output in HQP.
At the time I had no experience with an NAA, but I’ve since listened to Roon/HQP through an NAA on three devices. Apart from some artifacts in the Raspberry Pi when upsampling to DSD128 (see thread in this section) arising from the implementation of USB in the Pi (nothing to do with HQP), they all worked flawlessly and delivered excellent results.
I think a battery powered BBB running Jussi’s 134MB NAA image is the lowest cost small footprint renderer around. A CuBox-i is a little more expensive, but easier to setup and likely to give better results in a more demanding HQP configuration than I was using.
So I have a lot of respect for the NAA solution and am particularly pleased that Jussi has enabled such an inexpensive high quality rendering solution.
I still believe there is a market for a DSP style of HQP and tighter integration with Roon. The absolute SQ may not be as good as an NAA, depending on what RoonReady or RoonBridge device we are talking about, but it is likely to be better than direct DAC connection to a noisy computer. It would also open up a lot more Wi-Fi choices for users.
Now, however, may not be the best time to expend resources exploring such further integration. There are other important developments in Roon which deserve equal if not greater support. MQA is lurking and it’s not yet clear what a software decoder might look like and how MQA and HQP might interact.
In my ideal world, MQA and HQP would know enough about each other so that MQA software decoders in Roon and Tidal could take advantage of HQP’s filters as well as the end DAC. I’m not confident that this ideal world will come to pass. It’s a bit like hoping for peace on Earth and goodwill among men.
What has considerably brightened the landscape, however, is the mutual trust and assistance shown between Roon and HQP. The recent bug squashing efforts on both sides of the relationship have been most encouraging. I’m looking forward to what they each do next.
+1 Good post.
I think setting up HQP and RoonReady to work together would be a good idea, but I wouldn’t call it the highest priority for either program.
I am very pleased at how the latest versions of HQP and Roon are working together almost flawlessly for me.
thanks for your great input, @andybob
naa
turnkey solution
most of the possible naa devices do not look to me like a turnkey solution, which i would prefer.
on the other hand, something like the sonic orbiter se might be an idea.
soundquality vs roon loop back
i assume the final word about this is not spoken yet? maybe it depends on the implementation.
timeline of further integration between roon and hqp
i understand that there are also other important topics right now.
i just think i would make sense from a business point of view:
i dont think that the average roon user will go for the typical naa device. way too technical! a turnkey solution would be the preferred option, i think.
so in my ideal world, maybe 2 hqp solutions would exist:
1)roonready and hqp
2)naa, including there also turnkey solutions
Most of the uncompressed image size is empty space on partitions. There is about 20 MB worth of content there…
ExaSound Playpoint has HQP NAA and works really well. I suppose disadvantages are expense compared to a more diy solution; and it currently only works with an ExaSound DAC.
thanks for the hint, @Peregrino
looks very interesting! and also runs on wifi input, which could be an option for me (no more cables…).
have you an idea about the soundquality comparing ethernet (cable) input vs wifi?
I tried it with wifi only briefly, as I knew I would use wired Ethernet thereafter. It functioned fine but I didn’t compare sound quality.
I’m not sure why there would be a quality difference running RAAT vs NAA in a situation like this (CuBox, BBB, RPi, etc).
Obviously once you get into integrations into particular DACs/AMPs/etc, there will be all sorts of differences if you’re not comparing the same stuff.
As far as audio transmission goes, they are pretty much the same thing: a small C/C++ program running on a home-made minimal linux distribution on off-the-shelf ARM hardware that copies audio data from a network interface to an ALSA hw:X,X device.
I remember when Jussi said something about RAAT and quality, and I read it as the same “I don’t know how they did it, so I can’t vouch for the quality” kind of response that I give all the time when talking about other peoples’ products and not as an indictment or implication that RAAT was in some way fundamentally different or inferior.
I am concerned that his benign statement is being interpreted in a way that produces a perception that RAAT is somehow worse for quality. We’ve put a lot of attention and care into making sure that it’s done right. And if somehow, some relevant technical difference that was impacting sound quality surfaced, we’d address it.
Thanks Brian,
[These were the relevant posts] (http://www.computeraudiophile.com/f11-software/hqplayer-kick-start-guide-and-feature-requests-20870/index17.html#post487538) and as you can see Jussi was responding to my suggestion of a DSP style HQP module that could return output to any arbitrary program (including Roon), noting that there was a risk of negative SQ impact from such approach. We weren’t discussing RAAT and I have no reason to doubt that a small footprint device running RoonBridge would have an equivalent SQ to an NAA (leaving aside the processing by HQP). Certainly my RoonReady Aries sounds great.
I would dearly love to persuade Mr. Wang at Auralic that his real competition is with devices with inbuilt NAA rather than between Lightning DS and HQP (no one treats these programs as alternatives), but it has been fun to play with the small ARM devices.
Yeah, I remember. His wording/response didn’t/don’t bother me at all, and his viewpoint makes sense.
The risk in that approach is that the downstream software receiving the output stream from HQPlayer screws something up, and that that hurts HQPlayer’s reputation. Jussi’s ability to ensure quality for his customers is lessened if he has to trust 3rd parties with the audio.
That said, it is technically possible to pass a digital audio stream around without harming it, and if all Roon/RAAT had to do is get the bits to the sound card without mangling them…that’s not a very high bar for us to clear.
(Side note, I’m equating Roon and RAAT here because as of 1.2, there will be no more “local” Roon audio…RAAT will be used for local and networked endpoints. I’m sure at the time of these discussions the situation was a little bit different, and the terminology too).