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 
)