64 bit floating point volume control with DSD would be a nice feature. HQP can do it, so I’m confident the Roon team has the ability to make it happen as well.
And what would be the benefit?
No benefit with DSD.
It would allow the volume control to work with DSD.
HQP does it without any quality loss. But yes it consumes more resources. But it really should be up to the end user to decide if they want to buy a computer powerful enough to handle it. If they don’t want to do so, simply don’t use the feature.
And not sure why Brian says it would be best to implement in the low powered endpoint. HQP does it in the core. And with a powerful server, and fast network gear lag isn’t a concern.
Likely the real problem is they want ROCK and Nucleus to be able to run the full feature set in Roon. And if they implemented a DSD volume control, everyone would complain that Roon’s own server doesn’t have the balls to run it. A real shame.
As much as I like ROCK and the Nucleus server, it’s a shame that the chosen hardware is going to cap the future potential for Roon to take the software to higher levels of performance. All future features will need to be resource friendly enough to run on all the NUC’s. This means compromises will be certain.
Or possibly, the real ‘problem’ might be that it’s not a big deal for most of their customers, and for any that it is - Roon already provide HQP integration.
Hmmm, you should probably not make assumptions on hardware you have not evaluated nor about the reasons behind the decision to not support volume control. Did you even read the thread the post you responded to had referenced? If you had, you would have read this response:
@Brian directly states that one of the main concerns is that the endpoints ( not server) potentially not having the horsepower to do the processing. In addition, brian states:
[quote=“Brian”]It would also be distasteful to have a signal path that re-modulates
the DSD twice–once to process it in the core, and again to process it
in the endpoint later.
So no, we don’t do it. Too many compromises to make it a good feature.[/quote]
I don’t think anyone is passionate about having to buy a 3rd party software program that is a nightmare to run headless just to take advantage of DSD volume control. The problem is the NUC hardware just doesn’t have enough power to do it smooth.
Reality is HQP simply isn’t at the level where it can be a commercially viable OEM solution. Roon on its own is. Having the DSD volume control saves the $1000’s it takes to do a top quality volume control in the analog domain. For example parts cost alone for our top analog volume control comes to $1100 per channel. Industry standard markup is BOMx6 for gear sold through a distributor/dealer model. This makes this volume control a $13200 option for just 2 channels if used in a product that is sold through a distributor/dealer network. In contrast Implementing a DSD volume control in software only adds a couple hundred bucks to the server bill in order to have enough power to run smoothly. And will outperform the $1100 per channel solution as you don’t need to add any more components into the signal path.
Yes and there’s no need to implement it in the endpoint. HQP doesn’t. Roon doesn’t for PCM. So why would you for DSD? Makes no sense that you would offload an operation that the core can’t even handle to a low powered endpoint. I understand the lag issue, but it’s only an issue if your server hardware is weak.
Regarding hardware I haven’t evaluated, does putting the NUC SBC in a fanless case increase computing power? You’re right I haven’t evaluated the Nucleus case.
I’m starting to get that familiar feeling of déjà vu
Roon’s “DSP Volume” is always endpoint based. We do PCM volume control in the endpoint.
There are zero situations in Roon where volume control happens in the core today.
Same reason why we do it for PCM–because there’s a huge buffer between the core + the endpoint–about 5 seconds of buffer, actually. And 5 seconds of lag is not a reasonable user experience for volume control.
The large buffer is what makes RAAT stable on WiFi networks, poor networks in general, with underperforming cores, and so on.
To make a lag-free volume control, we’d have to reduce the buffer to ~200ms–which would be stable only for a small subset of our users. To turn that on for everyone would be a support nightmare, and reliability would go away for a vast majority of our users.
If we make it an option, it’s an option “only for good networks”–the problem is–people are TERRIBLE at self-selecting on this basis. Every single support issue that ends with a clear conclusion that the network is broken started out with someone starting the conversation by saying “my network is perfect”. It’s like how 90% of people think they are better than the average driver.
I can’t see how we make that option and not have it turn into a huge distraction/support nightmare. There are many possible reasons why someone might want to turn it on, and a large fractions of the real world setups that our users have would not be able to perform well with that setting.
Yes, HQPlayer does sever-side volume control. It is laggy (by our standards), and compared to RAAT, NAA is “only for good networks”. Very different objective and environment than Roon.
This has nothing at all to do with core performance. The core already knows how to do the necessary DSP for gain adjustments–we support volume leveling on DSD today, and a NUC5i3 can do that at DSD256.
The lag is the result of an engineering choice to build a more stable system by using larger network buffers. The lag is about 5 seconds, and does not vary with core performance.
The pickiness about the lag is because we care about user experience.
The reason not to do the option is because we care about making a product that does not have hidden pitfalls that make it difficult to support or error prone.
I hope that’s clear.
(Not subscribing to updates to this thread…too much work to do, and I’ve been distracted by this enough already )
Thanks for the explanation. I didn’t know that the volume control was implemented in the endpoint with pcm. I understand what you’re saying about the 90% not being able to run it due to weak servers and lousy network gear. And of course everyone will want to. It’s easier to just make it not available at all from a support position. However if implemented in a purpose built OEM system using powerful servers, and known network gear, I’m sure all of the compromises you mentioned could disappear. Perhaps it could be an OEM only option for OEM’s who are willing to use the hardware required to get the job done?
With HQP on a $600 Asrock desk mini and a $75 router I get non-existent lag with the volume control sending audio via NAA to my streamer.
If it was an option, if you clearly explained that a certain standard of hardware is required for smooth operation, I don’t think it should be considered a “hidden pitfall”. If you don’t have the gear to run it smooth, simply turn it off. You could have a warning that pops up and says no support will be provided if this feature doesn’t run smooth on your gear.
This is why we bundled quality network gear with our systems. Moving forward all networking gear will be built in our systems. There will be no option for end users to do things poorly. If they can press a power button, they will get 100% performance in any possible scenario. If they don’t, that means we failed not them. No excuses.