Thank you. If my AVR’s Dac is upsampling internally to 24/192 anyway I thought I should do the same in Roon. Unless the Denon 4520 uses the factor of 2 method also, in which case I should do the same.
Hi @brian what have you found with the the Dacs of popular AVRs and how they up sample internally?
Appreciate any thoughts and advice
Now you’re just showing off… 
Cool
Nah… I don’t even like DSD.
Actually, I can imagine some interpolation algos that would even alter the original samples. So maybe I am wrong on that front.
The vast majority of SRC’s do not preserve the original samples, since they’re using FIR filtering as part of the process.
Notable exceptions: Bezier, Closed Form. There are others, too, but those are the ones most loudly marketed at the audiophile crowd.
You mean you don’t like the way your particular DAC and DAC’s you’ve heard previously process DSD?
Big difference between that and talking about the format as a whole. Since all current ADC’s are SDM based, the format your PCM was in before the lossy conversion in studio DAW was pretty much DSD. The only way to truly judge DSD is with a pure DSD DAC. Not a mixed DSD/PCM DAC. Unless there’s discrete DSD and PCM sections such as with the T+A DAC 8 DSD. But then you’re also judging the quality of their clocking and analog filter implementation just as much as you are the DSD format. 1 bit DSD is extremely jitter sensitive, so results can vary drastically between different levels of clocking.
So there’s no harm done converting 176k to 192k, in your opinion? And no advantage in sticking with the power of 2?
Conversion for conversion’s sake from 176 to 192 is not really all that meaningful. Akin to eq. If you like it knock yourself out.
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
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.
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.
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.