[I edited this to include a screen of my signal path with DSP Volume engaged]
So I’ve now had Roon running for 3 months, and I love it. What I don’t like is how I have to control volume in my setup.
I run Roon Core on a powerful Windows machine with a Ropieeee Roon Endpoint running into my dac. I use the Parametric EQ DSP for speaker correction, so I have DSP running all the time.
My dac does not have built in volume control, and feeds directly into my amp. What I am trying to achieve is the simplest/purest signal path, which I am sure is the goal of many others with high quality Roon systems.
The best path (IMHO) would not include analog attenuation, or an additional step of digital attenuation in the endpoint, or even further on in the dac. A Roon Ropieee endpoint’s digital attenuation is not very high quality. However, since I am already using the Roon DSP engine, adding in a volume control within the DSP does not add in any degradation to the signal, it’s already being processed in this step, it’s just an additional calculation at 64 bits, and practically no bits are being lost.
I currently adjust volume by using the Headroom Management in the DSP and sometimes by adjusting the level of the Parametric EQ. But the Headroom Management only attenuates to 30db. The sound is amazing this way. This works ok for me because I am primarily controlling Roon from my Windows Desktop, and I don’t adjust volume all that frequently. Here is a view of my signal path with DSP engaged, note that it is also not bit perfect because of the DSP.
So, what I’d love would be a Filter or something in the DSP that does a level control, and optimally mapped to the volume slider in Roon. This would provide the easiest and highest quality digital attenuation Roon can offer (without taking into consideration what’s happening in a DAC etc). And this attenuation would probably be superior in fact to the digital attenuation that happens inside of most dacs.
DSP Volume uses the digital volume control in the Roon Endpoint device (in my case a Raberry Pi device), which is not nearly the same quality as the Roon Core DSP engine (which works in 64bit mode etc). I’ve tried it and it’s audibly inferior to my ears.
So wrong. Nothing controls the raspberry pi volume it controls the volume of attached DACs or HATs if device volume is used and the device has a volume control exposed to Roon. Fixed is just that , and DSP volume uses Roons DSP engine to control volume. Its not lossless. Use you amps volume to get the best sq and leave the DAC at fixed 100%. If you want Roon to control it then DSP Volume is your only option. You can get Roon to control an amps volume of it has an it remote by using a Roon extension and a Harmony hub. I use this to great effect in my 2nd system.
DSP volume is done within Roon, not on the device. It’s the same code as the headroom adjustment.
You should try again, if you heard a difference, there must have been some other issue. A lot of settings floating around, you may have heard something else.
I seem to recall that DSP Volume uses the same algorithm as Headroom Management, but the calculations are done by R.A.A.T. on the endpoint rather than on Core. This results in elevated CPU usage (about double is what I observed) on a Raspberry Pi endpoint. Also, if DSP is also engaged on Core, the signal is converted to 64-bits and back twice, resulting in two dithering passes.
If any of this creates audible artifacts is difficult to say, but I wish DSP Volume could be implemented further up in the signal path, with the more powerful CPU in Core doing the calculations.
I actually chatted with Roon support about this. See this signal path, the DSP Volume happens after it has gone to the endpoint and before the DAC. My Dac does not have volume control.
I should have clarified better: “Roon code” is the critical thing… Whether DSP volume is done by the Core with headroom adjustment or it’s done in the Roon Bridge or the device’s RAAT SDK, it’s all the same code.
I was one of the 2 people that designed/wrote this code
Anyway:
The reason you are seeing signal path lights different is a tricky thing for us to display, but it’s just a display concern.
The purple glowy light means “bit-perfect”. I don’t think there is any misunderstanding here, but this would be the Roon gold-standard.
The blue glowy light generally means “good” but not “bit-perfect”. This would be the same as the non-glowy greenish light, but we use this light to imply that you meant to do this as an improvement, instead of as a side effect to lose bit-perfectness. The SQ may be even better than “bit-perfect”, but that’s for your ears to judge.
DSP Volume and Headroom both are not bit-perfect, so they should both be green. However, we clump headroom adjustment in with the rest of DSP because clearly it will make the audio not-bitperfect, but you knew that and are still using it to enhance the audio.
You are reading too much about what the light says about the quality.
All that said, the weirdest thing you’ve said is this:
I’m not sure why you say that, but that is EXACTLY where you want the attenuation. Everything else is an approximation of trying to do it in the analog stages… this is the place you get it with the best resolution (near infinite resolution!)
If it’s the same code in the endpoint for volume leveling, then you are changing the signal to 64 bit floating point, applying the volume leveling, then taking it down to the signals resolution once again? So it happens twice in this scenario (in the Core & endpoint)? Am I describing it right? So a 16/44 file won’t get volume leveling applied while it’s 16 bit, correct?
I am using DSP for speaker EQ for an open baffle single driver system, and my EQ is mostly additive. I need to trim the signal with headroom management or the EQ filter. So volume leveling is already happening in my signal. Adding in one volume leveling step in the DSP, while its in a 64 bit state with your high quality code, is surely better than adding in an analog volume control after the dac.
I recently switched to an R2R dac, and I love it (and getting another soon lol). And I definitely prefer the sound without applying upsampling. Before the R2R I upsampled everything in Roon to DSD512. I only mention that because upsampling is frequently applied to reduce bit loss with 16/44 files etc.
I totally get what you are saying. But, the difference between running the Roon code that you wrote on Core vs endpoint is (potentially) significant, depending on the system. I don’t doubt that there’s a reason, but I still wish all DSP happened on Core.
Hi Danny, I setup some listening tests today. While I can’t test blindly (There are a few places I have to go in the interface to change it), I can give it a good shot. I used to be in the industry and developed (not programmed) both digital audio hardware and software, so I have a firm grasp of what to listen for when comparing digital streams. I used two pieces that I know well. Both I have heard 2nd or 3rd generation tape masters of, have also extensive experience with them on vinyl, and have high resolution versions to compare.
With 16/44, 24/192, then with DSD64. I used headroom management -16db compared to no headroom management and -16db DSP Volume. I am using a recent Allo USBRidge Signature with Ropieee installed to my R2R DAC without upsampling.
On PCM files, I could reliably hear a small but significant difference between DSP Volume and Headroom Management. The DSP Volume engaged had a slightly flatter soundstage, a bit more edge/sibilance on vocals with them pushed to the front a bit more, cymbals spat more than rang, bass was a bit less dimensional and tuneful. Not a big difference, but I could hear it. With the 16/44 files the difference was stronger.
BUT I hit a big snag on the DSD files. I was listening to the difference and it was bigger, and I kept saying to myself, this sounds more like PCM. After a few tries I looked at my dac and DSD was not showing, it was PCM! Looking at the signal path, it was indeed converting it to PCM at the beginning of the chain! I wasn’t expecting this, and I can’t use DSP Volume in this scenario, I listen to a lot of DSD. Could this just be unique to my setup? I am including screenshots.
Danny I also wanted to acknowledge that what Roon is doing is difficult. Doing DSP Processing to DSD files is unique, and one of the reasons I chose Roon. I was very frustrated finding a solution that would allow me to apply speaker EQ to DSD files without converting them to PCM. Which is why I purchased the lifetime subscription to support you guys.
And having one Core but an unknown number of endpoints with varying feature sets to support and design for is a unique challenge itself! Adding a change to DSP and volume leveling is not straightforward in that environment.
It’s almost definitely not going to happen, as volume is “special”. Volume requires near-real-time adjustment, and if you do it in the Core, it is subject to all types of buffering – possibly as long as the entire song.
When you change DSP it hiccups the audio, and it does that because it’s destroying the buffered audio, so new changes take effect as soon as possible.
@danny is there a clear visibility, on where at least on roon certified devices, the volume control really takes place?
I care much about this also influences my selection of renderers. I appreciate most analog volume control but remote controlled by the room volume setting. I hate dealing with two different remotes.
I think it would be a property worth while mentioning for the roon certified devices. So you know before hand what you will get.
Thanks,
Mike
Danny, so when I use headroom adjustment in the DSP, isn’t this the same as a volume level (except limited to -30db)? It’s the same calculation? At least in my system I don’t get any significant disruption when I change it, I don’t hear anything except maybe a tiny pause. I use it frequently to volume level while music is playing.
So I feel like I’ve come full circle to my original post. Because the solution presented, DSP Volume, converts DSD signals to PCM. Having a pure DSD signal path is a requirement for me, as I listen to a lot of DSD (currently 110 frequently played albums!), and I’ve invested in hardware that supports it.
We always enforce Roon Ready volume control do volume in analog if possible, or digital if that’s all they have (for example, a digital network bridge).
yah it’s practically the same thing. but where it happens is very different. I’m glad you think the pause is “tiny”. I hate it and find it to be the most offensive part of our DSP engine – but its a consequence of supporting so many network protocols and so many classes of devices. The buffer is being destroyed and the stream is restarting like you just started for the first time.
Asking for native DSD volume is something you can throw up in the feature requests section, but most people want analog volume control and not DSP volume, so I don’t think this will be a prioritized feature. But let’s see how it goes… maybe we can get it in…
I am interested how does the Bluesound Node 2i do the device volume control?
I have two dacs. The Node 2i and a Denafrips Ares II. I was using the Ares II with Ropiee and had the same DSP volume issue as described above. I could hear it.
I ended up placing the Denafrips Ares II DAC to the coax out of the Node 2i, this way the Node 2i handles the device volume and I get to use the Ares II as my DAC.
