Native DSD processing

Hi, in the new build 216, there is the option to perform DSP natively in DSD. I use DSP for EQ and in my signal chain, I see that DSD is no longer converted to PCM before EQ is applied, but why does it then get passed to the sigma delta modulator which when I click it says it is converting PCM to DSD? I’m just asking out of curiosity. Thank you! Hammer

Unlike with PCM, processing 1-bit DSD signals in their original form is not practical because 1-bit signals do not have enough dynamic range to perform common operations like volume adjustment, eq, mixing, or convolution directly on the 1-bit representation.

So when DSD IS processed, the input to the processing chain is a 1-bit DSD signal, but the output must have more dynamic range. In Roon’s case, we perform processing with 64-bits of precision, so whenever you process DSD, you end up with something like a “64-bit DSD”. This signal is at the same sample rate as the original DSD signal–which is crucial, because that’s what preserves DSD’s excellent time-domain qualities.

This “64-bit DSD” needs to be converted back into a 1-bit DSD signal (Sigma-Delta Modulation) so your DAC can understand it.

“64-bit DSD” uses the same physical representation as “64-bit PCM”. The sonic content looks markedly different–but in many cases the same signal-processing implementations can work on either type of signal. This is true of the Sigma-Delta modulator, which will happily convert either kind of signal into a sensible 1-bit DSD signal.

At this point, we’re down to terminology confusion. To many people, DSD means “1 bit”, PCM means “multi-bit”, and my usage of “64-bit DSD” above would be nonsensical. That documentation string is consistent with this understanding–because the S-D modulator is in fact converting from a multi-bit format to a 1-bit format.

To other people, there are more shades of gray. There’s a term “DSD-Wide” which refers to an 8-bit DSD signal that’s sometimes used as a representation during processing. We considered using that term in Roon, but didn’t want to accidentally imply to people already familiar with that term that we are only doing DSD processing with 8-bit precision.

I think we’re going to clean up that message in Roon to focus on the output format (a 1-bit DSD signal) without mentioning that the input is PCM. This should remove the confusion.

7 Likes

Thanks for the detailed reply - I can’t say I fully understand it, but I can tell you this new build of Roon sounds much, much better than the prior version! Thank you for delivering such a wonderful product!

1 Like

A post was split to a new topic: DSD converted to PCM?

Hi, sorry for reviving this thread but I have a question regarding the Sigma-Delta Modulation.

If I use the DSP for PEQ with native DSD in Roon there is the Enhanced Signal Path with Sigma-Delta Modulation indicated. I think I have understood the post from Brian with my poor technical knowledge.

But as a fan of DSD and PEQ/Convolution I wonder if that described process is lossless or lossy and hearable? I know a PEQ is much powerful for enjoying music but want to know how things work.

Thanks.

The word you’re looking for is “transparent”–which actually speaks to audibility.

It’s a better word than “lossless”, which can mean a lot of different things to different people based on context. Virtually all DSP operations are “lossy” in the sense that they are generally not reversible to obtain the original bits, so strictly speaking information is lost.

Parametric EQ/Convolution are not intended to be transparent–you are meant to hear the results. If you A-B test, you should hear a difference.

Operations like sample rate conversion or sigma-delta modulation are intended to be transparent. In other words, they should not change the meaning of the signal. That doesn’t mean that people don’t hear differences, but these are generally not areas where you should be concerned about audible losses in quality.

3 Likes

Hi Brian – volume levelling works in the DSD domain but software volume control (DSP volume) converts to PCM. Is this for technical reasons or is there an opportunity to also do software volume control in DSD domain? Thank you!

It is technically feasible, but it would change the performance properties of the system considerably. Right now, Roon Bridge and local zones are “lightweight” and all of the real work happens in the core. PCM volume control is nearly cost-free, DSD volume control is 100 or 1000x as costly from a performance standpoint.

At the time when these decisions were made, we felt that software DSD volume adjustment was likely to cause performance problems for a lot of people, particularly the large set of people using Roon Bridge on ARM based single board computers, but also people on a single computer who were perhaps doing DSD processing on the core, then adding a second round of DSD processing for the volume function.

In today’s landscape it’s worth entertaining, assuming the demand is out there, as hardware is faster and more capable, especially in the ARM world.

4 Likes

Thank you Brian. Is volume control very different than volume levelling then, which is already being done in DSD domain? I assumed it was the same.

It’s a question of where it is done. Processing done to the core happens prior to network buffers which add a few seconds of delay. This is fine for volume leveling but not for volume control which must be responsive. Volume control happens right before we hand off the samples to the driver within the audio endpoint. This could be a roon ready device, roon bridge, a phone or tablet, etc.

Roon generally assumes that cores have a lot of processing power to do expensive stuff like DSD processing but we don’t make the same assumptions about audio endpoints as they are much more diverse and often resource constrained.

Like I said above the constraints are less harsh than when this was originally engineered so the door is at least a bit more open for this now.

Fantastic — as long as it was optional then people with lightweight endpoints won’t be affected, and those with more powerful endpoints can get the benefit. Should I do something to put this in a request queue?

You can always created a Feature Request in Feature Suggestions and vote. Other users interested in it can cast votes and Roon can gauge interest.

As Brian says:

Done — thank you Dan and Brian.