Roon chokes converting DSD 128 to PCM 176 - HQPlayer doesn't

[danny2]

Core Machine (Operating system/System info/Roon build number)

Windows 10 64bit Roon 1.6 build 416;
Intel Xeon E 1246 board;
switch TPLink SG 1008

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Bricasti M5 over ethernet
Description Of Issue
Getting conversion speed of 0.9 and stuttering. If I do the same conversion on the same server but with Roon handing the DSD 128 file off to HQP and output to USB I have no issues. CPU load using HQP is about 20%; using Roon is about 13%. So how come Roon chokes on the conversion and HQP doesn’t?
Note: if I just send straigght DSD 128 over ethernet to the Bricasti I also have no issue, so I don’t think it is network related.

Thanks

[Henry_McLeod (Henry)]

I think Roon tries to use a single core unless you tell it otherwise. HQPlayer will share load by default. Go into sample rate settings and see if Parallelize Sigma-Delta Modulator is set to on. If no do so.

[danny2]

Good idea but it was already set to “on” for parallelize.

[Rugby (aka Daniel or Big Dan)]

try turning off “native dsd processing” and see if that makes a difference.

[Katun (Сергей Михайлов)]

@danny2 Could you show the signal path?

[danny2]

[wklie (Peter Lie)]

Disable native DSD processing, as @Rugby pointed out.

[danny2]

Ah, okay, that worked. Thanks.
I still don’t quite understand why. Is it because when processing as “native” Roon tries to convert directly to 176 and when in not native mode it does it in two steps (First to 352k and then to 176)?

I guess it makes sense that doing it in 2 steps is less resource intensive. I’m surprised it makes that much of a difference - the conversion speed is up by a factor of 3.

[Katun (Сергей Михайлов)]

Ah, okay, that worked. Thanks.

OK. And what is the signal path in this case?

[danny2]

[Katun (Сергей Михайлов)]

Really very strange. I would like roon staff to comment on this.

[cwichura]

DSD as a general statement is very intensive to process. Disabling “native DSD processing”, the first thing Roon has done is convert to PCM, which is much easier to process.

[Katun (Сергей Михайлов)]

OK. It can be understood that “native dsd processing” really requires large calculations when an interpolating filter is used, for example, 176.4 -> 5.645, and it is necessary to calculate values for additional samples sometimes with a complex algorithm requiring computational power. But in the case of a decimation filter, for example, 5.645 -> 176.4, everything should be much easier - you just need to drop extra samples. I repeat that I would very much like to know the technical details, at least in a popular form.

[Rugby (aka Daniel or Big Dan)]

You might find this post interesting

Struggles getting Native DSD processing to work

I think you understand the underlying tech, but the use of “decimation” is not appropriate in this context. The word decimation, in a DSP context, refers to a process that reduces the sampling rate–something that is not happening here. Changing from a single bit to multi-bit format in this situation is a completely lossless process–in fact, there isn’t even information loss (even in a discrete mathematical sense) until you begin processing the multi-bit form. Which of course happens immediatel…

[Katun (Сергей Михайлов)]

Thanks Daniel,

Struggles getting Native DSD processing to work

The goal of this text is not to give insight into what is happening under the hood–there is not enough room here to do that topic justice, and most people do not care.

I’m just saying that it would be nice if the roon staff found the time and “enough room” for this, despite the fact that the “most people” might not be interested.