DSP Up-Sampling features in Roon 1.3

If anything it will be worse, but depends on the clocks used in your DAC. if it uses 49.152Mhz clocks for the 48 multiples, then it will likely be worse. 49mhz clocks are very hard to make accurately, and rarely meet manufacturer data sheet phase noise specs. The 44.1 family uses either 22 or 45Mhz clocks. 22 are the lowest jitter, but the 45’s are consistently better than the 49’s. However a lot of DAC’s these days just generate a PLL from a reference which in this case results in poor jitter no matter which frequency is used. In this case it’s likely a wash.

Thanks Mike. I was looking for a technical explanation like this. I’ll stick with the power of 2 for these reasons. Much appreciated

1 Like

From a purely practical standpoint it appears to take more computing resources to upsample to non-power-of-2 rates, so if you want to upsample different streams to different zones, you may have a practical limitation to stick with powers-of-2 upsampling.

1 Like

Does Roon support both 44.1kHz and 48kHz multiples for DSD? Or does DSD upsampling always use a multiple of 44.1kHz?

I have a question about the resource consumption of the DSD upsampling filters. I’ve read that with DSD128 as opposed to single rate DSD, DACs can move down from 7th to 5th order without allowing noise in, yet be more resistant to dropouts and performance degradation. Does Roon’s own testing show 7th order to be more processor intensive than 5th? With HQP, which I have only used as an endpoint sparingly, I used the SDSM7 filter as my preferred choice.

So far I’ve found with 7th order filtering on my Gustard X20 I can’t really use my 2013 iMac for anything else simultaneously without dropouts, including web browsing. To my DSJ and HA-1, no issues since I’m not using the computer at the same time. 5th order is running while I type this and no dropouts at double DSD, but to my ears the 7th order filter might sound a bit better overall.

What are the best DSD upsampling settings (phase and modulator) to minimize processor usage? Would it be minimum phase and 5th order?

AVRs tend to have lower-end SDM-based DACs (and lots of them to support all of those surround channels and extra zones). I would try targeting their highest supported rate first.

44.1 multiples only atm

7th order is empirically more processor intensive than 5th order. It does more arithmetic operations per sample. It’s technically more accurate, and has a lower noise floor.

That said, most of the CPU load involved in DSD upsampling is not in the SDM–it’s in the PCM-domain upsampling stage that comes before it. There is no CPU usage difference between min phase and linear phase. The best way to reduce usage is to target a lower sample rate.

In Roon right now upsampling is done in the core so the compute power of the zones is irrelevant.

I am confused by your response? Because all of the processing happens on the core, if you want to simultaneously play multiple streams to different zones (and you have sample rate conversion enabled for each of the zones) it means that the core will have to do all of the sample rate conversions in parallel which, depending on the number of zones and your settings could take significant resources. Depending on your usage and the specs of your core machine, this might mean having to choose less computationally-intensive settings.

Hope this clarifies? Sorry my previous post wasn’t clear.

1 Like

That’s what I figured. Thanks for the quick response.

That’s my understanding. Upsampling a number of different Queues to DSD 256 and sending the outputs to a variety of Zones is supported in the Roon software, but you may need a Beowulf cluster to do it.

More of just a question maybe someone can answer… Previously when using Roon/HQP or Audrivana+ with my DAC up-sampling a 44.1 file to 352.8 and than playing the next song a 96kHz to 384 and back to a 44.1 to 352.8, I would then notice an underlying hiccup in the music every 5 seconds or so in every 44.1 song going forward. If I limited my DAC to max 192kHz no problems at all, so I figured it was a DAC clock issue with sample rate conversion for 8x up-sampled redbook?

I fully expected the same issue to happen with 1.3 and DSP, but to my surprise not one issue like this playing files at 352.8 then 384 and back (knock on wood)… just curious if anyone has thoughts why this issue is now gone? (I don’t want it back, but curious what 1.3 does right, that A+ and HQP doesn’t)

Hopefully this makes sense to people reading.

Indeed. That’s why I hope a future enhancement is to be able to have a Roon Bridge perform the DSP. I’m not sure whether this really makes sense or not though, I definitely could be overlooking something. I’m sure that it will come in time if feasible.

Hi Brian,
Is there a need for ‘Sigma-Delta modulator’ that does noise shaping, i.e, 5th order etc…when processing PCM to DSD conversion? If I understand correctly, Roon doesn’t use this when playing back DSD directly.

In the DAC end, the hardware does the Sigma-Delta plus noise shaping and the analogue signal goes to gentle LPF.

Sorry. Yes. Misunderstood your question.

You have to noise shape when going pcm->dsd if you want to produce a DSD signal that is very useful to anyone downstream.

Noise shaping shapes the noise floor so that more dynamic range is available at the frequencies where musical content exists, and less dynamic range is available at higher frequencies. Only after that’s done can you filter out the noise with a gentle LPF effectively. If it were un-shaped, noise would intrude on frequencies that you couldn’t reasonably attenuate without doing damage to the signal.

Noise shaping isn’t a step you can move to after the X->1bit conversion, though–you have to noise shape in order for the 1-bit DSD signal to make sense. What happens afterwards in the DAC varies–it might re-modulate, it might not.

While this may be true, I think it’s important to look at the real-world market that Roon [and similar companies] are appealing to

Roon has thousands of customers…and while only Roon can give us specific numbers, my best guess is that the majority of those customers have between 3 and 10 Zones in their homes…with very rare situations where 20 Zones might be used

I think it’s fair to say that for most of the above users, that they will only have ONE Highly Resolving system / Critical Listening rooms in their homes, with a DAC and Speakers that can benefit from the type of SRC / DSD Upsampling being discussed here…and yes, it’s possible that some people may have 2-3 highly resolving systems in their homes, but that is rare in my experience

Likewise, I also think it’s fair to say that there tends to only be one audiophool :wink: in the house…and if you’re lucky, your partner may also be similarly inclined, but again that’s rare IMHO…so that means that even in a house with two high resolving systems that benefit from SRC / Minimum Phase / DSD Upsampling…that means there would really only need a maximum of two simultaneous streams of the type being considered here

And so, even if you consider the “edge cases” of Roon’s user base…I think Roon has shown it can deal with 2-3 simultaneous streams feeding DAC’s & Systems that can usefully benefit from e.g. DSD256…whilst still dealing with feeding 16/44 music to up to 8 other, more “casual” listening rooms…but obviously the user needs to have a reasonably spec’d i7 with SSD and RAM as the Roon Server platform, to cater for such an edge case scenario

I think the key word here is simultaneous streams…and how many of them are really needed in a typical household…and I think it’s fair to say that Roon is more than capable of dealing with that :slight_smile:

5 Likes

I think doing DSP in Roon Bridge is inconsistent with the design goals of Roon Bridge as a lightweight program that can run on inexpensive minimal hardware without a substantial processor load. All those things are inconsistent with DSP, particularly upsampling at rates like DSD 256 and DSD 512.

What does the “processing speed” measure when you’re feeding HQPlayer? I’m seeing numbers in the 4000-6000x range…

Thanks!

It’s just measuring how long it takes to pack the stream up for HQPlayer. If it’s that high, it doesn’t mean much, and you can just ignore it.

This is fair, and probably the reasoning behind the Roon team’s recommendation of a 5th or 6th generation i3 or i5 for the core. My only point is that depending on how your system is used, there may be practical considerations behind upsampling within the same rate family rather than upsampling everything to the highest supported rate that have nothing to do with sound quality.

I think this is probably true.

The thing I really like about the HQPlayer integration is that it allows you to separate the hardware concerns into what is needed for your upsampling requirements and what is needed for your library. That is, you could choose a spec for your core based on the size of your library, and then add one or more boxes for HQPlayer based on how many simultaneous streams you need and how much processing power each of those streams require. With HQPlayer, if I decide that I want/need another upsampled stream, I can buy another appropriately spec’d box and all is good. With the current Roon model of all of the DSP functions happening in the core itself, now the potential processing power required for the core is unlimited. Whatever specs I choose for the core effectively limit the possible number of streams/DSP capabilities that my system will support. As unlikely as it may be in practice, if you want to support multiple DSD512 streams, with the current DSP design, this is a practical impossibility.

Fortunately, HQPlayer is still supported, so there are alternatives, but I’m just advocating that the HQPlayer model is a better one, conceptually. In practice, I wish is that HQPlayer could play to RAAT zones, and I look forward to HQPlayer Embedded 4 that should be able to run headless and integrate with Roon. I Guess I just want to have my cake and eat it too — I would like to be able to choose between using HQPlayer and Roon for DSP based solely on sound quality (or tweakiness) factors, not because I am forced into that model simply because it is not really possible for the Roon model to scale to meet my needs.

That being said, I don’t see any reason why Roon couldn’t support this model eventually. Perhaps this isn’t the intended function of the Bridge, and instead some day there is a new “RoonDSP” component (or Roon optimized DSP kit) that you can install somewhere to outsource DSP functions for one or more zones. I’m sure the Roon team wanted to keep things simple, and will add/support this if they sense the market demand makes the added complexity/support worthwhile.