Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
UniFi
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
NAD D 3045, connected to MacBook Pro via USB, Roon Bridge on the Mac
Description Of Issue
Although the NAD D 3045 has its own volume control and remote control, if I wanted to control volume using Roon Remote, I should be able to do so by enabling Roon’s DSP Volume feature for this output. When I do that, it breaks MQA Rendering (the MQA indicator on the NAD goes out and the signal path indicates that the DAC is no longer rendering).
This does not make sense to me, as I can apply all kinds of DSP to the signal path and Roon is able to restore MQA signaling so that the DAC can complete the final unfolds. In fact, I can simulate the effect of a volume adjustment by adding -8 dB to Roon’s Headroom Management DSP without disrupting MQA Rendering.
It seems like a bug to me that Roon’s DSP Volume appears so late in the signal path. It should appear before the “Bit Depth Conversion with Restore” for at least a couple of reasons. First, this would preserve MQA Rendering, and second, we want DSP Volume operations to happen on a 64-bit signal, not a 24-bit or 16-bit signal.
I’m sure there was probably a reason at one point to put DSP volume so late in the signal path, but I hope you’ll consider ways to move it to the same part that’s occupied by Headroom Management and other DSP functions (ideally, immediately preceding Bit Depth Conversion). It seems like this would result in better quality across the board.
I should add that I’m seeing a significant increase in the CPU usage of RAAT Server on my endpoint device after enabling DSP Volume. To me, this indicates that the math required to implement DSP volume is happening in Roon Bridge, not in Core. If so, this seems to be antithetical to Roon’s architecture…having Core handle DSP and processing and minimizing the work to be done by endpoint devices.
I’m sure there were reasons for your choice to implement DSP Volume where you did, but for the sake of audiophiles everywhere, I hope you will reconsider.
It is not possible to use DSP volume with MQA due to the architecture of RAAT.
As shown in the Signal Path, DSP Volume control is handled on the RAAT “endpoint” instead of the Roon Core’s DSP engine. This can be confusing as the RAAT “endpoint” is often running on the same machine as the core, but they are actually two separate entities. If you check Activity Monitor on your Mac you’ll see the “RAATServer” process, this is what handles DSP Volume as well as interfacing with the audio devices on your computer.
This architecture is what allows for instantaneous response of the volume control in Roon. Roon uses large (often multiple seconds) buffers between the Core and audio endpoints. If DSP volume was handled in DSP Engine there would be a latency of multiple seconds before the change in volume could be heard from the audio device.
RAAT is designed to be a multi-platform low-power solution to sending audio bits around your home. The advantage to this approach is that it allows RAAT to run on everything from a Raspberry Pi to a 64 core Epyc/Xeon workstation. DSP operations such as the MQA Preserve/Restore process are outside of the scope of what RAAT was designed to do.
Some comments from our CTO about the relevant design decisions can be found here:
Thanks for the reply. From the perspective of sound quality, this seems like a sub-optimal trade: sacrificing S/N and elevating endpoint CPU usage (more nose) to reduce latency in volume control adjustments. Please remember us audiophiles out here when you make design decisions.
It seems you have made this decision to support user experience for non-audiophiles, but it would be lovely to have an “advanced option” in Device Settings that allows us to choose to bump DSP Volume back to Core, before Bit Depth Conversion (with MQA Signaling Restore), with a brief disclaimer that this may add a few seconds of latency to volume control adjustments. In other words, allow your subscribers to make the choice on this trade-off of latency vs. signal to noise ratio. Thanks.
I should add that I agree with this philosophy 100%. I feel the same way about the scope of Endpoint processing, as a whole. DSP operations, such as MQA Preserve/Restore, Volume, etc., are computationally expensive and should be handled by Core whenever possible. I understand the compromise that you made here with DSP Volume. My audiophile sensibilities (which I understand are only shared by ~1% of your subscribers) prevent me from agreeing.
Thanks for considering the possibility of allowing the 1% of us to accept higher volume control latency to gain better sound.
Thanks for the link to Brian’s comments. This makes a bit more sense now. Not everyone (including me until now) is aware that “DSP Volume” in the signal path implicitly implies "Bit Depth Conversion to 64-bits, attenuation, and a subsequent “Bit Depth Conversion” to match the wordsize expected by the DAC’s driver.
Would you consider making these three distinct operations explicit in the signal path? I think this would make what’s happening much more clear to Roon subscribers. That clarity will help us to make better decisions around its use (including contemplating the purchase of a proper Roon Ready endpoint to eliminate the need for DSP Volume).
