Need an upgraded cpu?

With upscaling and convolution now possible, and assuming that I am interested in both simultaneously and that I listen to flac, dsd, and MQA, what are the recommended specs?

My current sonicTransporter i7 (dual core) cannot handle upsampling and convolution at the same time for flac files or any convolution for dsd files. It’s current.y configured with 8gb of memory – would increasing the memory provide any improvements or would I need a faster CPU (I’m not interested in upgrading CPU until I have a clearer picture of what Roon has in store for us in the future with MQA and mobile listening support)?


@Adeeb – when you play a certain setup, and click on signal path to bring up the popup, it tells you the processing speed… what does it say?

Hi @danny,

I’ve compiled this for you to better see patterns. Note that all of these tests were conducted with only one zone playing.

My convolution filter was created using REW and following the guide that @Magnus meticulously put together.

For SRC, I am using a Custom setting where all PCM data is up/down-sampled to either 352.8kHz or 384kHz (depending on the source file) and DSD is up/down-sampled to DSD256. I am also using:

  • Precise, Minimum Phase
  • 7th Order (CLANS)
  • 0db Gain Adjustment
  • parallelize enabled
  • native DSD processing enabled

I hope this helps determine if this is a CPU limitation or if I might expect better results by upgrading the memory.


On my computer (which is a modern i7 Intel desktop computer), I have processing speed over 18, and that is with volume leveling, sample rate conversion to 88/96 and stereo convolution filter with 131k taps. Adding some equalization to this does not make any noticeable difference, but I have not tested DSD (my DAC don’t support it).

Looking in the task manager, that means Roon is taking 0.5% to 1% CPU, which basically means I don’t notice it running when working on the computer.

Seems strange that your computer is so much slower, even if its not a proper desktop (I am not sure what sT i7 really is).

Thanks for sharing your results. Have you tried upsampling to 192kHz (assuming your DAC supports it) with the convolution enabled? Do you have any high-res files that you can try as well?

Sorry for the abbreviation – sT i7 stands for sonicTransporter i7. I have only had it for a few months, but it is the dual core version. They now sell a quad core model that is more directly intended for Roon 1.3 DSP functions, but I would rather not have to replace my Roon Core server so soon.

Unfortunately since the sT is a closed solution, there is no way that I know of to check CPU or memory utilization. I don’t know which is the main/first bottleneck.

Looking at your top three lines - it’s interesting that your individual steps of upsampling and convolution are each around 15-17x, but together only 0.5x.

That doesn’t seem right to me.

Have you looked at RAM useage during the ‘both’ vs ‘individual’ config? If it’s not RAM, its perhaps a software issue?

I wish I could check CPU & memory utilization, but the sonicTransporter is a closed system and I don’t see any way to see such a report.

The reason I have posted these results here are to try to get feedback from Roon as to whether these scores are in line with their expectations or not based on my current hardware, and to get feedback as to whether adding more memory (currently 8gb) might improve the results in a significant way. On the other hand, if I am forced to upgrade the CPU then I would have to replace the whole unit (to account for extra cooling requirements), and I’m not ready for that.

Of course, there is a chance that more software opitimization would help – whether in Roon Core or in the sonicOrbiter OS, but I would need @danny and
@agillis to comment on that.

Ah, OK, that’s a shame. Closed systems…

Well, at least to me it seems a bit unusual that both processes can be used individually at 15-17x, but together only at 0.5x. Something is wrong somewhere along the line, but where I couldn’t say.

[quote=“hifi_swlon, post:8, topic:24358, full:true”]
Well, at least to me it seems a bit unusual that both processes can be used individually at 15-17x, but together only at 0.5x. Something is wrong somewhere along the line, but where I couldn’t say.
[/quote]Agree, that shows some bottleneck hitting the limit.

For me,

  • only convolution = 44x
  • convolution + up-sampling = 18x
  • convolution + up-sampling + 16 band PEQ = 12x

All those are with volume handling enabled (track). The up-sampling is only to 88/96 khz though, since my DAC can’t handle more.

Make sure you have “Parallelize sigma-delta modulator” enabled or Roon will only use one core for upsampling.

hi andrew. yes i already have it enabled.

any way to check cpu/memory utilization?


I see two things here.

First–our Convolution engine is probably not up to the task of running anything but a very tiny filter at DSD sampling rates. This is the same use case that pushes the HQPlayer people to spend thousands on dedicated upsampling machines with expensive GPUs on board. There is some room for optimization in our Convolution engine, too–but I can’t guarantee that optimizing the code will get you there by itself (or have a sense you what hardware you might need) until that work is done. So using “Enable Native DSD Processing” and Convolution together might not be practical. I recommend the Native DSD stuff off for now if you’re having trouble combining it with other processing.

Once you do, convolution will only be happening at 352.8kHz and 384kHz–which seems like it should be very practicable.

Except in your data, it isn’t happening.

There’s another performance pitfall that you might be running into, too. Maybe you’re having Roon up-sample the convolution filters and they are getting very large?

For example, if you provide us a 131k tap filter at 88.2kHz, then attempt to convolve at 352.8kHz, it would seem like 4x as much work is being done to generate 4x as many samples. The problem is: it wouldn’t be correct to use your original 131k tap filter at 352.8kHz since it would change the meaning of the filter. Instead, we need to up-sample it, just like the signal.

So that 131k tap filter is resampled to a gigantic 512k tap filter. So Roon is not doing 4x the work–it’s actually doing over 16x the work. That’s a big multiplier–enough to take a situation that would have been stable before and make it unstable.

Most software generates the same filter order regardless of the sampling rate–REW and Acourate both fall in this category. So they’ll make a 65k or 131k tap filter for both 44.1kHz and 352.8kHz. They can do this because they understand the meaning of the filter that’s being generated–whereas Roon must blindly resample because we don’t know the internal details of the filter.

I’m not sure if this is happening with you–but if you were to generate convolution filters at each sample rate where convolution might be taking place, and put them all in a zip file it may help.

This is a signal path that I run very comfortably on a NUC5i5. Your sonicTransporter is probably a faster machine. In this setup, the convolution always happens at 352.8kHz, and the filter was generated by Acourate. I think it should be possible to get to someplace like here on your transporter.

this is what i’m doing already. every sample rate supported by REW (up to 192) is generated and gathered and a zip for use in Roon.

no idea why my PCM upscaling + convolution is performing so poorly.

That is still a pretty huge filter at 352/384. If I recall right, REW generates 131k tap filters regardless of the sample rate…so after upsampling they are double or more. 131k taps is pretty oversized for rooms in houses at PCM rates…

It would be much better to have REW generate native filters, or even 65k tap filters instead. I understand that that might not be possible in its current state.

It would be interesting to see how much impact there is cutting down the filter size to 131k or 65k @ 352.8/384kHz and eliminating all filter resampling from the equation.

(Or alternately, running Roon at 176.4/192 instead to see how much of a difference that makes).

Or maybe manually input numbers in Roon EQ instead of using REW wave files would help? Takes a few minutes to do it though and easy to get wrong, but in this case it might be worth to try (you probably have do disable 4 filters in REW before generating the response, since Roon only supports 16 EQ filters).

1 Like

You can always stack two Parametric EQ’s–one with 16 and the other with 4. The result will be exactly the same.

1 Like

Yea, of course :slight_smile:
Do you mean the sound will be the same, or the performance, or both?

EDIT: to clarify, will using an impulse file from REW be the same as manually input numbers in Roon PEQ?

Both. Our Parametric EQ is based on a cascade of IIR filters. So you’re just adding more filters to the sequence.

The reason for the 16 filter limit is all about the user interface–keeping it manageable, readable, workable on tablets, and keeping the colors distinct.

No, but not in a way that establishes a clear “winner”. We’re using IIR filtering, whereas REW is generating a convolution (FIR) filter.

That said, I think their filter generation mechanism is–essentially–just a simulated IIR impulse response being interpreted in an FIR model. So it should be extremely close even though the filtering mechanism is different.


Hi @brian,

I have made the following changes and retested all the cases I had before. The updated results (which also includes some typo corrections from the previous one) is attached below.

The Changes

  1. Instead of the previous SRC settings to up/down-sample all PCM to 352.8kHz or 384kHz (depending on the source file) and to up/down-sample all DSD to DSD256, I now up/down-sample all PCM to 176.4kHz or 192kHz (depending on the source file) and to up/down-sample all DSD is left at DEFAULT.
  2. I have deactivated the Native DSD Processing

DSD Notes
A. All DSD is converted to PCM 352.8kHz even when SRC is disabled due to the Volume Leveling
B. In the event that I have SRC enabled, the signal is further down-sampled to 176.4kHz due to the PCM sampling settings mentioned above

Other Notes
C. I am still using the same REW zip convolution file as before.
D. When I have more time, I will try manually entering the EQ settings in Roon instead for comparison

E. For ALL file types I tested, I am now able to play the music with both SRC and Convolution Filters enabled.
F. For DSD files, I was not able to use Convolution unless I also a) Disable Native DSD Processing and b) enable SRC and sample to 176.4kHz or 192kHz (rather than 352.8kHz, 384kHz, or anything higher).

It is not ideal (on paper), but I will need some time to assess if these changes sound like an acceptable compromise.

Brian, what’s the advantage in applying the convolution to the upsampled signal (and possibly needing an upsampled filter), rather than to the native signal, and then upsampling the result?