Hi @support:
I just acquired Accurate and made the convolution filters all the way up to 384k
When I play the DSD files, Processing Speed is doing to 0.8-0.9x
Convolution Filter says “2 path 1051k taps”
PCM files has no issue.
The music will play for few seconds and stopped.
Please help.
In addition to the last question for @support
I read some other threads and seems like applying the Convolution filter on DSD file is not possible, unless I turn off “Enable Native DSD processing”, but I have a question:
When the DSD file is playing with the Convolution filter, the NUC fan does not turn on at all, and seems like the CPU is not even under load.
Meanwhile, I remember when the Rock core is running the file analysis, the NUC fan is super noisy, on full blast
Is that somehow the ROCK Core is not using all the core for the DSP (my config has set Parallelize Sigma-Delta Modulator ON)?
Over one million taps… That’s a pretty long filter. 
@brian can probably answer your question about multi core processing and convolution. In the mean time: could you post a screenshot of your signal path so we can see what’s going on?
Sure, when I get home, I will take a screenshot of that.
I know it sounds a bit abnormal for that many taps.
When playing PCM files, it says 66k taps, and that’s completely fine.
But I when play DSD with “Enable Native DSD Processing” on, it has this crazy 1051k taps number.
Without “Native DSD Process”, DSD converts to PCM then the filter is applied with 66k taps, which sounds “normal” to be and the processing speed is hovering around 9.8x to 10x
Like again, when the convolution filter is on, the fan is working super quiet, doesn’t look like the CPU is under stress even it said Processing Speed is 0.8x
I zipped up all 8 WAV files from Acourate and sent to Roon. Should I use “dbl” files instead?
I apologize if I might have asked too many questions on one thread
Ask away! 
I’m not your best sparring partner however, since I don’t do DSD at all and use Dirac for RC outside of Roon.
I’ve added ‘Acourate’ to your title – let’s see if some Acourate users can chip in.
Thanks @RBM!
This is all new to me, from setting up the recording mic to designing a target curve. Acourate developer Uli was very helpful too.
Since your filter package doesn’t include a filter that matches the DSD sampling rate, Roon has to pick one of your existing filters and upsample the filter to match the content.
The number of “taps” is just the number of samples in the filter. When convolution filters are upsampled, the number of samples increases, just as with any upsampling, hence the larger tap count.
This is certainly a bit wasteful–the best case scenario would be to generate a filter for each of the DSD rates that is the minimum size that would work. The problem is that the Room Correction software is in a position to know what that minimum size can be–it’s not something we can reliably determine automatically.
As things stand today, convolving DSD in Roon is not very practical. Moving forward, we will be releasing a new FFT engine that should make it possible in many more configurations. It’s very possible that that will fix your performance problem.
While Roon does scale some DSP processes across multiple cores (namely, sigma delta modulators, if you turn on the setting), convolution is not one of them. So 0.8x is a reflection of one CPU core doing the work. If you have many cores, the machine as a whole may not be working very hard, but we are still bottlenecked–and that is what the processing speed indicator is showing.
Thanks @brian for your explanation.
I will play around with the settings.
At this moment, with “Native DSD Process” off seems to work okay with around 10x Processing Speed
I will just wait for future update on Roon to resolve this.
Thanks for the support,
P.S.: I just sign up for lifetime subscription this week for this great product!
Just a quick question.
Besides a FFT engine you mentioned, is there any plan to support multi-core processing for Convolution filter?
Not at the moment, no.
Multi-core, as an idea, sounds a lot more appealing than it is. A lot of people like to think of it as an obvious first step, but it doesn’t make things any more efficient, it’s just a technique that allows Roon to consume more of the machine’s resources to get a job done.
Consuming more resources means that any speedup or increase in capabilities is coming at the expense of something else. In Roon’s case, we are always trying to balance the constant grinding load of DSP against the need to keep CPU resources available so that browsing, focusing, searching are responsive. These suffer greatly when overall system load is too high.
We also are trying to balance the potential for people to be running many zones on a system at once. Optimizing the DSP engine to encourage the load for one zone to spread across 3-4 cores will not scale to multi-zone systems on reasonable hardware.
This is why we would much rather spend our effort speeding up single-core performance, and use multi-core techniques when we run out of options–since improving the performance of the algorithm is actually increasing efficiency, and doesn’t edge us closer to overall resource bottlenecks at the machine level, like multi-core options do.
BTW, the speedup from the new engine is a lot bigger than what you would have seen from multi-core–multi-core would have only given us 2x for stereo content (one channel per core) minus the overhead associated with splitting up the processing to multiple cores. The the new engine is 8-10x more efficient on a single core. It totally changes the performance landscape for convolution in Roon.
Good to know, and again, thanks for your detailed explanation! 
Are you possibly misinterpreting (i.e. inverting) the processing speed metric? For example, 0.8x is slower than real time processing; the CPU cannot keep up with that level of loading. And 0.8x indicates much higher load on the CPU than 10x processing speed, which is 10x faster than real time.
AJ
last night, at 0.8x, it can’t play at all, the Convolution Steps indicated 1051k taps.
I reboot the ROCK Core, now DSD64 (1x) plays with 524ktaps at Process Speed 1.3x, which seems fine now
you mentioned: “Are you possibly misinterpreting (i.e. inverting) the processing speed metric?”
Is there a setting I could have missed causing the “inverting”?
I also notice, even at 524taps, DSD64 plays okay, but the vocal sounded biased to the left (see signal path screenshot in previous message).
With “Native DSD Process” off, there is no problem, the vocal is centered.
I don’t think there is a filter issue, because when it is applied with the PCM path, it sounded okay.
I will just keep Native DSD Process off for now as Devialet converts to DSD to PCM internally anyway, and it sounds very nice with this signal path even it is “green”.
Thanks
I don’t know what you’re hearing–but it doesn’t make sense. There is no chance of crosstalk (unintentional mixing between channels) with that signal path.
Hi @brian
I found this old thread and this user seems to have to similar issue
I am not sure the cause either, but when I do A/B test with or without “Native DSD Process” on, with Native DSD Process on+Convolution, the vocal is definitely shifted to the left.
Native DSD Process off (DSD converted to PCM first), no crosstalk with Convolution filter
Let me clarify:
DSD–>Convolution–>DSD Crosstalk
DSD–>PCM–>Convolution Normal
I have 8 filters from 44.1 to 384k, no DSD filter in the zip.
Do I need CFG files in the zip so that Roon will recognize which WAV to use for Convolution each bitrate?
I can provide you with zipped filters as needed if you want to investigate the phenomenon.
Right now, it is not too much of a problem for me, and I don’t mean to cause any trouble as you informed me you guys are working on at the different Convolution Filter already
I will use the Path above for now as it is more stable also (9.4x), and sounds good too.
Anthony
@support, can you please make sure these files end up in a ticket with @Anthony_Chan’s problem description?
