Better Volume Control

I think you’re wrong. Roon does all its processing at the core.

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.

4 Likes

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.

3 Likes

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.


1 Like

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 :wink:

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!)

9 Likes

Thank you for your time and insight.

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.

You both make good points. It’s complex to build an adjustable routing engine for DSP without creating a mess of a product.

I’ll have a talk with the team. I stil think the analog is far better than any digital, but each to their own.

Can you both hear the difference between dsp volume and headroom adjustment?

Can you identify it blindly?

I’m asking not to attack, but to prioritize the effort.

7 Likes

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.


1 Like

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.

1 Like

Volume control with dsd will convert it to PCM.

1 Like

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.

2 Likes

@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.

So is a better volume control possible? :slight_smile:

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…

1 Like

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.

Can RAAT transport 64 bit floating point to the endpoint when doing DSP volume control in combination with Core DSP engine? Or does the output of the DSP get downconverted to 24 or 32 bit for transport over RAAT and then reconverted to 64 bit on the endpoint to perform VC attenuation?

I can read my path, and the signal is resampled to the original bit depth (if you have no upsampling engaged) when its sent to the RAAT.

A post was split to a new topic: Can I have volume control of my Roon on phone?