AudioFilterStateVariable: why is the code written twice?

[tigger]

I've been looking through the code for the AudioFilterStateVariable (...\Arduino\hardware\teensy\avr\libraries\Audio\f ilter_variable.cpp), trying to understand the filter better.

the part that does the state variable filter ("Chamberlin Filter") looks like it has the filter coded twice (sort of).

// now do the state variable filter as normal, using fmult
input = (*in++) << 12;
lowpass = lowpass + MULT(fmult, bandpass);
highpass = ((input + inputprev)>>1) - lowpass - MULT(damp, bandpass);
inputprev = input;
bandpass = bandpass + MULT(fmult, highpass);
lowpasstmp = lowpass;
bandpasstmp = bandpass;
highpasstmp = highpass;
lowpass = lowpass + MULT(fmult, bandpass);
highpass = input - lowpass - MULT(damp, bandpass);
bandpass = bandpass + MULT(fmult, highpass);
lowpasstmp = signed_saturate_rshift(lowpass+lowpasstmp, 16, 13);
bandpasstmp = signed_saturate_rshift(bandpass+bandpasstmp, 16, 13);
highpasstmp = signed_saturate_rshift(highpass+highpasstmp, 16, 13);
*lp++ = lowpasstmp;
*bp++ = bandpasstmp;
*hp++ = highpasstmp;

is was expecting something more like...

input = (*in++) << 12;
lowpass = lowpass_delayed + MULT(fmult, bandpass_delayed);
highpass = input - lowpass - MULT(damp, bandpass_delayed);
bandpass = bandpass_delayd + MULT(fmult, highpass);

bandpass_delayed = bandpass;
lowpass_delayed = lowpass;

*lp++ = signed_saturate_rshift(lowpass, 16, 12);
*bp++ = signed_saturate_rshift(bandpass, 16, 12);
*hp++ = signed_saturate_rshift(highpass, 16, 12);



It looks like there is a two sample box car filter on the input ( ((input + inputprev)>>1) ) and an averaging of the two "instances" of the filtering ( signed_saturate_rshift(lowpass+lowpasstmp, 16, 13) ).

Can anyone tell me the reasoning behind the design?

[tigger]

Ok. I found some explanations here...

https://www.musicdsp.org/en/latest/F...sampled-stable

the extra code boils down to trying to make the filter more stable.

[MarkT]

Its because its 2-times oversampled.

[tigger]

Hi MarkT,
I did finally see that it was 2x over sampled, but I figured it would just adjust the parameters accordingly and run the simpler code. But the musicdsp.org site had some more explanaitions.
Thanks for the response.

[PaulStoffregen]

Changing to 3X oversample is on my todo list....

Can anyone tell me the reasoning behind the design?

The filter's feedback loop becomes unstable when the configured corner frequency is too high (relative to the sample rate), particularly when combined with low resonance. Oversampling by 2X guarantees we use only the bottom half of the range, which makes most applications stable.

[tigger]

Changing to 3X oversample is on my todo list....

Thanks Paul. Do you think this will help with the harsh noise that happens with this filter?
See the following thread...
https://forum.pjrc.com/threads/67358...unwanted-noise