Any possibility to access and control HQPlayer filter and settings from inside Roon ?
If I got it right, HQPlayer embedded is meant for such implementation.
Even if you say no, it is technically possible to do, right ?
I want to achieve a headless HQPlayer, where filters and settings can be controlled by a user interface in Roon.
I’ve shifted your post to Feature Request as it is not concerned with ROCK.
So far as Roon is concerned I would suspect that the devs are more interested in extending and developing their own DSP engine (which is available to all users) than extending the HQP integration (which is only available to HQP subscribers).
Embedded HQP does not support network control, so you wiould need to speak to Jussi about that. I asked him about it shortly after the integration was released and he didn’t indicate it was a high priority for him.
Use of an NAA to separate the computer running HQP from the Ethernet/USB renderer makes running a GUI on the HQP computer less significant for SQ.
It does now, and it works fine with Roon 1.3.
The UPnP Renderer functionality part existed already before, so now there are two parallel control possibilities. Of course the one used by Roon offers much wider access to HQPlayer functionality.
Jussi, does it mean we can control the up sampling filter change through network call? Anything we can try on? And which version of HQP need to install?
If I understand Miska correctly, that’s what he is saying. Now it’s up to Roon to implement such possibility.
This could be a win/win situation for everyone.
If not I hope there exists an app developer out there that is willing to make a simple control interface for the filters in HQPlayer.
As a start it only need to copy the settings in HQPlayer.
I no the answer is no, but still I hope one day you guys may consider adding the possibility to have HQPlayer embedded on the same hardware.
Of cause the controlling interface to HQPlayer is another issue.
Thanks @jussi_laako for clarifying that. I should have checked before assuming embedded HQP had remained the same. Could you expand on the above ? What HQP functionality is accessible through Roon but not through a UPnP renderer ?
If you are referring to ROCK, it is very unlikely. It’s design parameter is Roon Server only. As soon as anything else is allowed the devs would be inundated with “Why hasn’t my preferred thing been allowed ?”
ROCK is meant for people with little or no Linux smarts on very specific hardware. People who want to run headless Roon Server and embedded HQP are not those users and can reasonably be expected to use a headless Linux distro of their own choice. They will also usually want to use more powerful hardware, including a CUDA GPU, to upsample with HQP to DSD 512 and ROCK is not designed for that hardware.
I didn’t mean accessible through Roon, but accessible through the same control API that Roon uses. But one example of extra functionalities not possible with UPnP is the capability to display selected filter, modulator, output mode, etc. Roon doesn’t currently fully utilize what the API offers…
Just to clarify the DSD upsamling and HW.
It has been stated that it is Roon intention to support DSD 512, and I think it already supports 256
Anyway I would expect ROCK to support same up-sampling as the other Roon platforms. And judging from the suggested NUC, there are powerful i7 versions available. So I would expect DSD 512 is possible if that version is chosen.
So I find it a bit strange to exclude HQPlayer embedded based on possible weak HW. Or technical issues in general.
If you could clearify a bit more please ?
If I understand things correctly, it’s possible (technicality) for Roon to use and access what most us see as the core and best part of HQPlayer, the upsamling algorithms and filters etc.
And if I understand Miska correctly everything is ready from his side that this can be done.
That Roon may not like to offer such an option, for paying HQPlayer customers is another thing. We do not have to discuss that, apart from this request, and your confirmation that it is possible.
I do believe that if people knew they can get the best from two SW’s and in addition by use of only one piece of HW, instead of the today’s recommended two computer solution, they may choose it, and therefore it should be looked at as a winning situation for everyone.
I can’t see the downsides, but I’m sure you can enlighten me, as maybe my understanding of how things could be utilized is just to good to be true ?
Firstly, I’m not a Roon employee, I’m a user like you and a volunteer moderator. The “Community” designation in the titles indicates user members of the Community as distinct from Roon staff. (Don’t let my “real” jellyfish fool you !). I think your questions and points warrant a response from someone who will know as distinct from guess (like me) and let’s flag @brian to see if he can tell us anything in that regard.
Having said that I can clarify my guesses a little more so you can see my reasoning.
Firstly, ROCK isn’t a version of Roon, it is a stripped back Linux that does nothing but run Roon Server. The only control surface accessible to users will be a very simple Ethernet/Wi-Fi configuration. The Roon Server it runs is the ordinary Linux Roon Server. It will have no greater or lesser functionality than Roon Server because it is Roon Server.
The purpose of ROCK is turnkey operation on a limited set of hardware (Intel NUCs) for folk (like me) who are unfamiliar with Linux. That’s it. It is likely that there will be improved SQ for those who connect a DAC directly to their computers, but that is not the recommended architecture for Roon. The recommended architecture is a server/renderer configuration where the signal is sent firstly to a Roon Ready or Roon Bridge device and then to the DAC. ROCK is unlikely to result in any SQ improvement with that recommended architecture because the things it improves are already taken care of in that architecture.
ROCK’s simplicity depends on sticking to its design parameters. As soon as ANY expansion beyond Roon Server is contemplated the number of variables expands to the point where it requires a far greater development and testing effort than the purpose warrants. The testing required for even the simple case resulted in deferral of ROCK beyond 1.3 and is ongoing.
That is why I feel confident in guessing that we won’t be seeing ROCK support other programs, including HQP. Users who are adept enough to have an appetite for their OS to run something else can use a Linux distro.
The hardware point is that ROCK has been announced as supporting i5 configurations, but i7 are on a “lets see if it works” basis. In relation to DSD 512 my personal experience is that an i7 by itself may not have the grunt to oversample Redbook to DSD 512. My i7 7700 stutters at DSD 512 without CUDA GPU assistance in HQP. CUDA requires a CUDA capable graphics card. ROCK will not support external graphics cards.
I don’t know if it is technically feasible to bring more HQP control within Roon. What I am saying is that it seems more likely to me that development resources will be spent improving Roon’s own DSP in preference to a closer integration with HQP.
I’m a fervent HQP fan. I currently have to control my stereo through an iPad using:
I would dearly love to see some of all of the above in a single interface. But for the reasons set out above I think it is unlikely.
This is part of a somewhat bigger project to support additional “playback controls”. Several Roon Ready partners also want this for switching filters/phase at the DAC, doing channel trimming controls, and other stuff like that. HQPlayer is one of about 10 partners that would benefit from this sort of integration. In addition, we would make the same capabilities available via the Roon API so people could attach extra controls of their own (or integrate with other things).
I think we’ll add support for this via the Roon API, via the RAAT SDK (for Roon Ready partners), and in all likelihood for HQPlayer, too, using its control interface (and even if we were to de-prioritize the HQPlayer specific piece for some reason, it would be possible to accomplish the same using the Roon API anyways).
I noticed some implication that we might “focus on our own DSP” or that there might be business reasons not to do this. I don’t really see it that way. We don’t lose anything when our users use HQPlayer, and we don’t gain anything when they use our DSP. Both should remain viable options and work well. Just because we have a little bit of overlap now doesn’t mean we intend to marginalize that integration.
Sorry to ask a somewhat naive question but, has ‘Rock’ been released?
If it has iS there also a list of ‘approved’ hardware?
Still in alpha testing as far as I’m aware. If your next question is: “when will it be released” - then the answer that the Roonies always give is: “when it’s ready”.
This sounds great Brian. If I understand your answer correctly, some “magic” may happen
Will be exiting to see where we are a year from now. I’ll try to be patient
Thanks for telling us this.
Thanks Geoff ,that actually was going to be my next question!
A straightforward ‘turn-key’ solution would be super.
This would be fantastic Brian. I’m running DSD512 HQplayer upsampling on a headless machine so it would be fantastic to not have to VNC into it to make simple changes.
Great to be able to experiment with HQPlayer filters from within Roon.