Roon's 64 bit floating point volume leveling

Hi @brian

I’ve seen comments scattered around the forum discussing whether Roon’s 64 bit floating point volume leveling is lossless or not.

I have volume leveling on Auto and the average volume leveling figure for my music library is around -12dB

I have a basic understanding (which could easily be wrong so please correct me) that for every approx. -6db in volume leveling there is a 1 bit truncation (or loss?) in the output resolution. So every 6db drop in volume leveling in Roon, 1 bit of resolution is lost?

Or does Roon’s conversion to 64 bit floating point mean that my understand of the above is not true? And that all bits are preserved? Again, with the example of -12dB volume leveling.

Please correct me if I’m wrong. I’d rather get the info from the Guru than keep reading all different bits (pun intended) around the web about digital volume control in general or how other software packages manage this. So as lifetime Roon-er I want a better understanding of how Roon does this for me.

For this question, assume Roon’s output volume is “fixed” and ASIO drivers are used in Windows (ie. always Exclusive Mode essentially).

Before anyone asks whether I can hear a 1 bit or 2 bit loss in resolution, the answer is probably/maybe no. But I do like understanding (at a high level only ) what Roon is doing along my signal chain.

Much appreciated

Usually, there is enough extra headroom available to make quite a large adjustment without losing any precision.

The 64bit number isn’t really involved in this discussion, because it is never the bottleneck for precision. There is always a smaller precision bottleneck somewhere between Roon and the DAC–typically 24 or 32 bits. Very occasionally there is a 16bit bottleneck–but this is limited to very old or very cheap devices not marketed at audiophiles.

Lets say you’re starting with CD quality content–16bit 44kHz. If you play that without volume leveling turned on, there are 16 bits of meaningful data there, and all of them will go to the playback device.

Now, say we turn on volume leveling and do a big adjustment like -18dB, so three bits. After the adjustment, we have a signal that has zeroes in the most significant three bits, and the signal has “moved down” and is now consuming bits 4-19 instead of 1-16 like before.

The key is–Roon tries to avoid truncating that signal back to 16 bits again. Instead, we’ll send it out to the device as a 24 or 32 bit signal, to maintain full precision. As mentioned above, this is possible in the great majority of situations.

There really is not any meaningful amount of 32bit (or higher) source material–even “32-bit” DXD uses 32-bit floating representation, which only has 24bits of actual precision.

One case where precision is actually lost: when you play 24bit source material through volume leveling to a DAC that can only take 24 bits. This is not the theoretical ideal, but it’s also not particularly damaging in real life. There will virtually always be a dynamic range bottleneck further downstream in the system anyways.

For me, the benefits of volume leveling outweigh this small unavoidable compromise.

Here’s an example:

Just like I explained, we’re starting with 16bit content, applying volume leveling, but at the end, we truncate to 24bits to preserve the precision before sending it to the device.

11 Likes

Fantastic, thanks @brian

How does any of the above explanation change, regarding volume leveling, when having Roon up-sampling to 1bit DSD?

Assuming one has a NOS DSD capable DAC

That explanation really only applies to PCM.

With DSD, the full 64-bit floating point stream goes into the sigma-delta modulator without truncation. There is not a volume leveling adjustment possible that would cause us to lose information in that scenario.

2 Likes

Brilliant.

Really appreciate this.

Would it be possible to do a software volume control if one playback pure DSD?

Not currently…there is a horsepower vs user experience problem.

We insist on putting volume control in the endpoint to minimize lag/latency when changing volume. Doing a DSD soft volume control would consume a lot of resources. Many endpoints in our ecosystem are not powerful enough to perform the adjustment.

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.

Hello Brian,

SEAN2016 directed me to that thread as i asked here
digital volume attenuation

Should that threads merged or do you please reply there ?

Robert

Reviving an old thread as the question is in context.

1.5 seems to have increased the CPU utilization significantly when volume leveling is enabled or perhaps I just didn’t pay close attention <1.4.

Is this expected or do I have something else going on perhaps?

My loads go from ‘no value’ +100 with leveling off to anywhere from 15x to 2x depending on source bitrate.

Thanks

There have been no changes in that area for a long time. In 1.3 we released DSP engine (which of course changed things, but not as dramatically as that), and a couple of months later, we improved DSD processing–which could have made volume leveling more expensive for DSD content, but would not change anything for PCM.

For MQA content, if you have a MQA Full Decoder product, volume leveling would have become more expensive in 1.5 since that causes Roon to decode the MQA prior to leveling it, but that’s kind of a corner case.

A view of the whole signal path might be illuminating here–it’s hard to reason about this with only 10% of the details.

I’m not near my system but will be later. No DSD, No MQA (though I do have the Roon decoder enabled). I noticed it with both an MP3 320k stream and a FLAC 44.1k stream. No DSP, cross-feed is enabled.

No reported CPU util (above 100x) without volume leveling, ~10-14x for MP3 stream and ~2-5x for FLAC stream with volume leveling enabled.

It’s not a problem per se, no dropouts, I just hadn’t notice the CPU hit in the past. I can send screen shots tonight if it would be helpful to further explain.

Yeah, the screenshots will tell a clearer story.

Image uploading appears to be broken for me, error

uninitialized constant EXIFR::JPEG

@Brian I have a question regarding Volume Leveling and I noticed that you have described the process in quite some detail. My question is regarding +gain modifications through Roon’s Volume Leveling.

I have a convolution filter running on my ROCK to apply some room corrections. However, as expected I get clipping warnings if I don’t adjust the Volume Leveling either by creating some headroom or by performing Volume Leveling. I have chosen the latter and applied a Volume Leveling of -14LUFS as I don’t fancy having to crank up the volume excessively on my AMP. The result in some cases is that Roon applies a positive Volume Leveling (as can be seen in the picture underneath).

Now for my question, is it sonically unfavourable to have Roon apply a positive Volume Leveling gain? Meaning I have to opt for possibly -23LUFS? Or does this, compared to a negative gain, have no additional negative impact on the sound quality. I can’t hear any difference to be honest, but I just want to understand how this works and how Roon possibly alters the sound quality.

Thanks in advance.

Roon should only apply a positive gain up to the peak level in the content. So if the content has a -0.3dB true peak, the max positive leveling adjustment is +0.3dB.

This avoids a sound quality problem, at the expense of sometimes not being able to accomplish the full called-for positive adjustment to hit your target volume. A minor compromise at most…which can be offset by setting a quieter target.

Personally, I like -14LUFS. It’s much more important to make too-loud content come out at a good volume than slightly-too-quiet content slightly-louder, so this is a good tradeoff.

The -23LUFS R128 target is intended for broadcast applications…not music listening. The MLA recommends -14LUFS for music.

4 Likes

Thanks for the detailed explanation @brian, it’s appreciated!

1 Like