@jussi_laako, yes in screenshot, matrix HAF is enabled.
Direct DSD without any matrix, it’s 4/5 % CPU.
Flac with matrix is 45% CPU
I tried “normals” and “shorts” HAF filters… is the same !! over 90% CPU (screenshot with “short”).
Finally, I found an acceptable solution via HQP while going through PCM and using the HAF 768 matrix on my i5.
Moreover, in DSD, the differents matrix haven’t no impact (CPU overloaded).
If I want to keep DSD direct … with HAF matrix, impossible !!
In the end, it is necessary to choose the right PCM filters in the DSDSource Settings menu.
By choosing poly-short-mp as the PCM conversion filter, I lower the CPU consumption to 65% for HQP and DSD > PCM > HAF matrix > PCM works.
In fact, it is valid for all filters except poly-ext2 or poly-mp / ln (80% HQP, 90% overall)… and I had selected poly-ext2 
So, I can read my DSD but only in PCM, by optimizing the conversion before applying the matrix.
@jussi_laako , what is the right filter for you to minimize the impact of the conversion before switching back to PCM 768, poly-sinc-ext2 / LNS15 ? thanks ! 
Small filter length adjustments usually don’t matter, so it is better not to try over optimize the filter lengths, just create something that is good. If you change the filter length by 2x then it begins to make difference. But in many cases and modern hardware filter sizes don’t really matter that much until you start doing multichannel, DSD256 sources, or similar.
Maybe “standard” as noise filter and “poly-ext2” conversion. I think this is the current default.
You mean “traditional” and “wide” (for 768).
No, PCM Noise Filter = standard, PCM Conversion = poly-ext2
Yes… i read too quickly, but not poly-ext2, it use 80% of CPU (DSD to PCM with matix enable / 4 channels).
And “standard” as noise filter but poly-short-mp as PCM conversion (60% CPU).
Normally I just upsample within PCM. But when I try the conversion from PCM to DSD (DoP), I’ve noticed that if I try to convert to DSD for a high-res file in Roon (either Tidal or Qobuz), the file doesn’t play. If I play the same track in its 44.1/16 format, no problem.
Anyone else experience this?
Check that your SDM rate limit is set to multiple of 44.1k and that you don’t have adaptive output rate checked. Most DACs don’t support DSD at multiples of 48k.
Got it. That made it work.
But it’s pretty choppy. Not really a big deal, as high-bit-rate PCM sounds fabulous. Was really just curious why I couldn’t get it to work.
So, what makes it choppy? Is it the DAC? The limitations of the machine/processor hosting the Roon core or bridge?
Likely you are running out of CPU power for the selected filter. I’d recommend to try -2s variants of poly-sinc filters, or poly-sinc-ext2. In case you are trying to go with a single stage filter at the moment.
And how to characterize the poly-sinc-hb versus poly-sinc-ext2 filter (or xtr-mp) with PCM 707/768 (LNS15) ?
Probably a very silly question…but if LNS15 Dither is used (linear) is it best partnered with a linear filter (for synergy), or does that not matter?
Thanks
It doesn’t matter, filter and dither/noise-shaper are independent of each other.
1 Like
poly-sinc-hb is non-apodizing, while poly-sinc-ext2 is apodizing. While poly-sinc-xtr-mp is kind non-apodizing (or to limited extent) minimum-phase filter.
I’m currently trying poly-sinc-long-lp but I’ve noticed something weird :
Sticking to 44.1 files, playback starts immediately
Switching to a 24/96 file, playback takes more than 2 minutes (!) to start
Switching to a 24/192 file, playback takes more than 35 seconds to start
Switching back to 44.1, playback takes 25 seconds to start
Once playback starts everything works fine.
poly-sinc-long-ip/mp start playing immediately, as do poly-sync-xtr and other filters I tried.
I’m upsampling to DSD 128 (modulator = ASDM7EC) on a Nuc 8i7 running Ubuntu 18.04 and Roon.
The DAC is a Luxman DA-06.
In all these cases, output rate is multiple of 44.1k base? poly-sinc-long can take a very long time to initialize when crossing between two base rates. From 48k-base to 44.1k-base output the time is still within practical. While going from 44.1k-base to 48k-base multiple the time becomes very annoying with most current CPUs.
Hi Jussi,
yes in every case output is set to 44.1 x 128.
What I don’t get is that as long I play files with the same sample rate, playback starts immediately. It’s only when I play a file with a different sample rate that I get these very long start times.
For example if I play two 24/96 files one after the other, the second file starts playing immediately. If I then play a 44.1 file, I have to wait 25 seconds for playback to start.
Some of the previously done initialization data is cached, that is why restarts of same source sampling rate are faster. Since most of the content is 44.1k, it is most of the time fairly quick operation.
Yes, this works as intended. When there is change in the source rate, full re-initialization happens. Most of the filters are pretty quick, but unfortunately the process for poly-sinc-long can take quite a while. This is because it belongs to same group as poly-sinc-short and poly-sinc, but since it is longer filter it takes longer to initialize too. The time rapidly grows, almost exponentially.