My 2 cents on 1: yes we always pre-compute filter coefficients, especially since they often involve trig functions which are expensive. I've rarely seen them actually stored as a filter, but if your application is to have many filters operating in parallel it's a good idea, but requires you to use FIR filters and no IIR filters. I'm used to seeing implementations where you instantiate objects that represent filters, and set their coefficients in some sort of initialization phase, which doesn't necessarily benefit from storing them in memory together or not. If you _are_ using FIR filters, and you are computing many outputs from one or more inputs, you can benefit from some matrix math libraries, but again that's under pretty specific conditions.
To contribute to the conversation on 2: In theory when you change the filter coefficients the states are relevant to a different filter, but computing the new states is expensive and non-trivial. I've never come across anything in the literature that explains it. In my experience some topologies are worse than others. If you have very large state variables, which happens when you compute the poles before zeros, then you end up with higher probability of audible clicks/pops. See this question where I asked about changing filter parameters on stack exchange https://dsp.stackexchange.com/questions/11242/how-can-i-prove-stability-of-a-biquad-filter-with-non-zero-initial-conditions/11267#11267 (especially Hilmar's answer which gives a lot of practical advice). Regarding SIMD and GPUs, the crux of what makes a DSP processor different from a CPU is highly-optimized SIMD, so yes typically DSP engineers are optimizing for SIMD, but not by using the GPU. Take this part with a grain of salt, but if I understand correctly GPUs have much higher parallelism than typical CPUs (something like 128 vs 4 operations). GPUs do, however, have their own memory, and transferring between the CPU and GPU has always been described as expensive. When you want low-latency operation (which you always do for audio), that memory transfer is at least something to think about. So those are the typical arguments against using GPUs for audio DSP, but I'm not aware of anybody who's actually tried it. If you have the skills I highly encourage trying it and sharing your results with the list. Something tells me these are probably arguments that are highly outweighed by the computation efficiency of a GPU, especially if you're not changing filter coefficients very often. Anecdotally, I've started to hear whispers from some audio DSP folks who are starting to prefer MISD operations of SIMD operations, and reducing buffer sizes as low as single-sample to get high performance out of their CPUs with very low latency. I haven't heard yet if this is easier or not. It might make implementing algorithms and optimizing them much more decoupled for audio DSP, but I haven't really tried it out on anything I've made yet. Again, if you have the skills for that type of optimization, I'd highly encourage trying it and sharing your results with the list. Has anybody else tested MISD vs SIMD optimization techniques on DSP? -Stefan On Sun, Jan 12, 2020, 16:33 Ross Bencina <rossb-li...@audiomulch.com> wrote: > On 12/01/2020 5:06 PM, Frank Sheeran wrote: > > I have a couple audio programming books (Zolzer DAFX and Pirkle > > Designing Audio Effect Plugins in C++). All the filters they describe > > were easy enough to program. > > > > However, they don't discuss having the frequency and resonance (or > > whatever inputs a given filter has--parametric EQ etc.) CHANGE. > > > > I am doing the expensive thing of recalculating all the coefficients > > every sample, but that uses a lot of CPU. > > > > My questions are: > > > > 1. Is there a cheaper way to do this? For instance can one > > pre-calculate a big matrix of filter coefficients, say 128 cutoffs > > (about enough for each semitone of human hearing) and maybe 10 > > resonances, and simply interpolating between them? Does that even work? > > It depends on the filter topology. Coefficient space is not the same as > linear frequency or resonance space. Interpolating in coefficient space > may or may not produce the desired results -- but like any other > interpolation situation, the more pre-computed points that you have, the > closer you get to the original function. One question that you need to > resolve is whether all of the interpolated coefficient sets produce > stable filters (e.g.. keep all the poles inside the unit circle). > > > > 2. when filter coefficients change, are the t-1 and t-2 values in the > > pipeline still good to use? > > Really there are two questions: > > - Are the filter states still valid after coefficient change (Not in > general) > - Is the filter unconditionally stable if you change the components at > audio rate (maybe) > > To some extent it depends how frequently you intend to update the > coefficients. Jean Laroche's paper is the one to read for an > introduction "On the stability of time-varying recursive filters". > > There is a more recent DAFx paper that adresses the stability of the > trapezoidally integrated SVF. See the references linked here: > > > http://www.rossbencina.com/code/time-varying-bibo-stability-analysis-of-trapezoidal-integrated-optimised-svf-v2 > > > > 3. Would you guess that most commercial software is using SIMD or GPU > > for this nowadays? Can anyone confirm at least some implementations use > > SIMD or GPU? > > I don't have an answer for this, by my guesses are that most commercial > audio software doesn't use GPU, and that data parallelism (GPU and/or > SIMD) is not very helpful to evaluate single IIR filters since there are > tight data dependencies between each iteration of the filter. Multiple > independent channels could be evaluated in parallel of course. > > Ross. > > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
