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…
Cheers
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.
Cheers
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: DaisySP/Source/Filters/fir.h at master · electro-smith/DaisySP · GitHub
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.
Cheers
Hi,
Just finished. It is based on fir.h and ex_fir.cpp.
You can just set the EQ parameters (Gain, Frequency, Q-factor, type)
Available types are: Lowpass, Highpass, Lowshelf, Highshelf, Parametric EQ, and Notch filters.
Here it is:
https://github.com/kienphanhuy/Daisy-Seed-Project/tree/main
Here is a picture of the filters responses performed by the Daisy Seed. I used a focusrite 2i2 to measure the response using sinesweep.
Here is another version of the code with pot control. This is an acoustic guitar tonestack programmed for the terrarium interface (this time it uses the petal library and terrarium.h).
Is that Terrarium project complete? I only see code for one knob.
Very helpful! thank you! Would make a very valuable addition to DaisySP
Here is the tonestack
https://github.com/kienphanhuy/Daisy-Seed-Project/tree/main/TerrariumTonestack
But if you can make one pot you can make many.
I don’t use the petal library anymore. I went back to the seed library … My project is not finished. EQ is just one part.
