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

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.


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.

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

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

@danny2 Could you show the signal path?

1 Like

Disable native DSD processing, as @Rugby pointed out.

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.

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

1 Like

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

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.

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.

You might find this post interesting

Thanks Daniel,

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. :wink:

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.