Convolution filters files format (bitdepth / sample rate)?

Hi all,

I’m using ROON DSP to convert and upsample sources from 16b/44.1 Khz to DSD 128 or DSD 512.

I want to apply convolution filters for Digital Room Correction purpose.
What is best compromise regarding filters files format (bitdepth, sample rate) , my concerns are about sound quality and computer ressources optimization ?

Thank you.

I’m not sure if this is what you are asking, but with the convolution, you don’t need to compromise in terms of sample rates - you simply create a filter for each sample rate, and combine them in a ZIP file. During playback and with convolution turned on, Roon then chooses the filter that is correct for the sample rate.

Thank you @extracampine,
My original source files are mainly “red book”, FLAC 16/44 (very few 16/48).
So from your explanations convolution is applied before upsampling and DSD conversion in ROON DSP engine ?

Convolution happens after upsampling PCM but before SDM conversion to DSD from PCM. It’s not possible to apply convolution filters to DSD directly (similar reasons as to why it’s so hard to master recordings in the studio in DSD - everyone uses PCM). If Roon can’t find an exact match in your filters for your upsampled PCM rate then it would take the next best and use that. See my attached - I upsample redbook to DSD 256 and the convolution happens at 352.8/384 khz PCM, and then conversion to DSD occurs.

Now, I used REW to generate filters and it only supports up to 192 kHz so Roon is (hopefully) using that one. Unfortunately if you want to upsample to DSD it looks like Roon always upsamples the PCM to 352/384 even if your device is forced to only accept up to 192khz in “device setup”. So there is now way avoid Roon having to interpolate the 176/192 filters for use at 352.8/384 in my case. I don’t know if Acourate can generate filters at 352.8/384 and I wonder how much this interpolation of the convolution filter impacts SQ.

I let Roon upsample to the DACs max with “power of 2”, and then I use convolution filters for the two highest possible bitrates that Roon ends up using. That way I only need to bother about 2 bitrates, and the convolution filter does it’s work at correct bitrate (no internal up sampling inside the convolution).

HI @Magnus, I know that you used REW to generate your filters, correct? (As per your awesome guide). So that would mean you have filters at 176/192 as REW doesn’t support 352/384. This would imply that your DAC’s max is 176/192 to avoid Roon upsampling the convolution filter?

Well, actually I only have a DragonFly Red so max is 88/96, but I have plans to upgrade. A pity REW cant handle higher bitrates ( also has a max of 192), dunno about Dirac and Accurate.

What happens if you set max upsampling to 192 in Roon, and then use DSD but use convolution filter after upsampling to 192?

So I tried to get around this by setting my “Device Setup” to MAX PCM at 192 (even though the device, an SMS-200 supports up to 384). But as soon as SRC to DSD 256 (DOP) is enabled Roon ignores the device setting and upsamples the PCM to 384 first. Which is logical as the device’s max PCM rate is irrelevant if you are upsampling to DSD xxx. Even if set my SRC to DSD 128, it still upsamples the PCM to 384 first, not 192 as I thought it might since 192 -> DSD 128 over DOP is the same fixed multiplier as 384 -> DSD 256 over DOP. So there seems to be no way around this.

I also tried HQPlayer (I still think upsampling sounds a bit better with HQPlayer) and it has an entirely different method -

a) it only allows you to specify 1 convolution filter (rate) and it up/down samples from that.
b) it doesn’t do a two step process like ROON from what i can tell - it does convolution at the source rate and then upsamples to DSD in one move. So with a redbook file it takes my 192khz convolution file and downsamples by 0.25/0.22xx to get 48/44.1, and then applies the convolution file, and then upsamples to DSD 256.

@brian can you impart on thoughts as to the impact on SQ if a convolution file needs to be resampled before being applied? I am assuming it’s insignificant.

fyi, Dirac only support 192 as well.

Seems to be a limit in Roon, the path you would like is:
up sample to 192 -> convolution -> up sample to 384 -> EQ etc -> DSD

Not that I think the SQ difference will be great. but its not like up sampling gives a big boost in SQ to start with, and I imagine convolution and EQ and higher bitrates will give slightly better SQ.

Yes I agree, though I would be happy with this:

up sample to 192 -> convolution -> EQ etc -> DSD

I just read this in the Roon KB page about convolution:

You can avoid filter resampling by providing a separate filter for each sample rate. This can improve performance–both CPU performance and sonic performance–so you should try to provide a filter for each rate when possible.

This makes me wonder how if there is an impact from me using 192khz convolution with DSD upsampling in Roon - the file will always be upsampled by 2x. Though HQPlayer downsamples as well - it doesn’t allow for multiple convolution filters as does Roon.

Maybe there is some third party app that can up sample the convolution filters, or for that matter maybe some dev at Roon can spend a few minutes to fix one (they have all the advanced stuff done already).

I will send an email to REW creator and ask if there are any plans to increase the limit in REW (chatted a little with him about the REW guide earlier).

Interestingly, if convolution is disabled in Roon then it will upsample Redbook 44.1 to DSD 256 in one step. It only breaks the upsampling into 2 steps if convolution/peq is enabled. Whereas HQPlayer does convolution first and always only does 1 step of upsampling.

@brian would it be possible to get roon to apply convolution/peq before doing any upsampling in 1 step, as opposed to PCM upsample, then convolution/peq, then SDM upsampling? Then one could guarantee exact filter matches and also reduce a step in the DSP chain. Or is there a reason Roon chose to do convolution/PEQ after PCM upsampling but before DSD upsampling??? Thanks!!

Thank you @nquery and @Magnus,

So in my use case: “red book” to DSD 128/512 + convolution the optimal setup for convolution filters would be:

  • With ROON DSP: 2 convolution files at 352.8 and 384 kHz ? (if it is possible to get a tool to generate filters at these rates)
  • With HQPlayer DSP: 1 convolution filter at 44.1 kHz ?

Correct ?

As it stands, that seems to be exactly the case. Note that if by “RedBook” you truly mean only 44.1 then only 352.8 would be required for Roon (but not harm in providing 384 as well of course). If you are also including 48khz then HQplayer would end up resampling the 44.1 filter 48. I think that from what I recall from HQP forums, it’s better to provide the highest necessary/possible convolution filter rate to HQPlayer.

@nquery, you are perfectly right. I’ve just asked to @Miska about HQP see:

We do it after PCM upsampling because it’s better to do the processing at a higher resolution, with a higher resolution representation of the filter’s impulse response if we’re going to be outputting at a higher rate anyways.

We do it before DSD upsampling because of the huge cost of running convolution filters on DSD rates would mean that it was only in reach of a few people with very fast machines. For most, it’s barely possible to convolve with high-rate DSD source material, and adding the cost of the upsampler on top of that would make it unmanageable.

The benefit of doing the processing way up there (compared to at 352.8kHz) has an extremely tiny effect size. Also, very little of the software out there is willing to spit out filters for DSD rates anyways, so we generally will not get a richer representation of the filter to begin with.

Also, there is broad precedent for performing mixing/mastering at 352.8kHz (DXD) prior to authoring DSD rate content. So what we are doing (concentrating DSP there as a “stop along the way” from PCM -> DSD) is very comparable to something which often happens in studios anyways.

It’s small, but I’d still rather avoid it. Not because I think I will hear the difference, but more because I want to run the filter as it was generated by the filter generation software, and not a processed version of it–even if that processing is transparent. Also, upsampling filters changes their order, which changes their computational costs, while most filter generation software does not increase filter order with increasing sample rate–so using a filter that matches your signal path’s needs without resampling can improve CPU usage.

Ok thanks for your comments - that all makes sense. Not that I am trying to set off a debate, but it is interesting that HQP has chosen instead to apply filters at the initial source rate and not an intermediate high PCM rate.

Regardless, guess we need to get REW to increase their export limit to 384 from 192, as currently there is simply no way to avoid filter resampling if one upsamples to DSD in Roon with a filter < 352/384.

Thanks again.

[quote=“nquery, post:18, topic:30742, full:true”]
Regardless, guess we need to get REW to increase their export limit to 384 from 192, as currently there is simply no way to avoid filter resampling if one upsamples to DSD in Roon with a filter < 352/384.
[/quote]I have sent an email to John Mulcahy (REW creator) and asked for it. Haven’t got a reply yet though.

Thanks for doing that.