G’day All,

Anyone tried using the CMSIS-DSP biquad functions?

I notice that DaisySP has a biquad implementation and was wondering if there was any advantage to using it instead of the CMSIS-DSP ones?

I want to modify the filter coeffs directly, so I’d need to adjust the DaisySP code anyway…


You should have no problems getting it to work. Or maybe TDF2 version would be more suitable, it should be slightly faster. Either way, I’d expect CMSIS version to have better performance due to block based processing. The only advantage from not using that I can think of is that resulting code is portable.


So I did get this to work - seems a-ok.

There were some gotchyas to look out for though - I was generating my filter coeffs using octave’s tf2sos(B, A) function.

Note that the transfer function used in octave’s filter is:

          N                   M
y(n) = - SUM c(k+1) y(n-k) + SUM d(k+1) x(n-k)  for 1<=n<=length(x)
          k=1                 k=0

where c = a/a(1) and d = b/a(1).

Whereas the ARM DSP uses:

y[n] = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2] + a1 * y[n-1] + a2 * y[n-2]

i.e. the a coeffs have opposite signs and the a0 column of 1.0s are removed

This brings up a questions though - I’m doing block processing using the 48 that is hard coded in all the daisy setup files. This is good as @antisvin points out it should reduce overhead. However libdaisy requires all DSP functions to be single sample based. What is the reason for this? I’d like to include this stuff as part of libdaisy eventually, but I’m reluctant to move to single sample calls for this.


You obviously was going to say DaisySP rather than libDaisy. Well there are cases when per sample processing is required - typically if you DSP graph contains feedback loops. Other than that, it makes little sense as the only choice to me.

I was asking about the same thing considering ways to add SIMD NEON intrinsics and was told that ideally all DaisySP objects would contain both block and sample based processing methods. I don’t think that anyone is actively working on this. But you could try opening an issue/PR in guthub, it would likely be accepted upstream if you add an extra method similarly like how it’s done for FIR:

They’ll obviously want the same ProcessBlock function to work even if it doesn’t run on ARM so a generic implementation would also be required, you can see how it’s done in fir.h with USE_ARM_DSP / arm preprocessor variables. Not sure if they’ll want separate classes like it was done for FIR or just a few checks. Either way, it makes more sense to discuss DaisySP contributions in github rather than here.

Yes - brainfade - DaisySP is the intended target.

That’s a very nice example - thank you. Is it yours? I’m just getting started in C++ world, so I think it’ll take me a while to grok the templates etc, but I will study it and see if I can create something similar for the biquads.