[LAD] A short technote on digital state-variable filters

Fons Adriaensen fons at linuxaudio.org
Sun Nov 22 13:09:01 CET 2020


On Sat, Nov 21, 2020 at 10:17:31PM +0000, Gordonjcp wrote:

> I guess with the corrected parameters, you can't get it to self-oscillate
> without Q really being infinite? 

Apart from numerical precision issues which could occur for extremely high Q.
For anything required in audio processing there won't be any problem.

> With the uncorrected parameters it seems to go "over unity" with Q set to
> about 10

The actual value will depend on the resonance frequency.
 
> It behaves well if you interpolate the c1 and c2 values to sweep the
> filter across a block of samples, which is handy.

You'd have to interpolate the 'd*' as well. Not for stability but in
order to maintain the required response during the sweep.

The way I do this is in gain controls, equalisers etc. is in two steps:

Define some internal block size N, independent of jack period etc.
I normally use something like sample rate / 100 (i.e. 10 milliseconds).

1. Every N samples, check if the user parameters (e.g. center frequency
   for an EQ) are equal to the current ones. If they are not, then

   * Move the current value towards the user value at a controlled rate
     (for example limit the frequency change to one octave).
   * Recompute internal parameters (e.g. filter coefficients) using the
     new current values.

   Big changes in any user parameter may require more than one step to
   reach their target.

2. Within each block of N samples, if the internal parameters computed
   in (1) are not equal to the current ones, use linear interpolation.
   If they are equal, optionally use a version of the DSP code that
   skips the interpolation.

The block size N and the rate limits in (1) should be chosen such that
there is no apparent delay to a human user.

This requires a lot of extra logic and code (much more than the actual
DSP code in most cases), but the result is a process that will never
produce clicks or pops and is therefore safe to use in e.g. a live
performance. Impact on CPU load is minimal since most of the work is
done only every N samples, and only when user parameters change.

Ciao,

-- 
FA



More information about the Linux-audio-dev mailing list