IIRFilter questions

So I thought I’d use IIRFilter for a small job today rather than my regular home brew filtering routines and I have two questions:

  1. It’s got locking for the coefficient setting stuff. Why was this important/how are people using this? I’ve not found a need for this feature and I’m wondering if I’m missing out on some snazzy second thread filter calculating technique :slight_smile:

  2. Perhaps processSingleSampleRaw should be kept in the header file so it can be nicely inlined…?

cheers! J.

Necro’ing this thread to say, I’m in the same place with the same questions now. Did you ever figure out the importance of the locking in IIRFilter::processSamples?

I guess, because it is not defined, which thread calls setCoefficients. If it happens from the message thread, you cannot allow processBlock to run processSamples.

If it is called from the audio thread, the SpinLock won’t have any effect anyway…

But it is superseeded by IIR::Filter anyway, where this problem is solved by using ReferenceCountedObjects as coefficients, so they can be swapped in a single operation.

Thanks for bringing that up. Yeah, actually I’m a bit confused by the overlap in the functionality between IIRFilter and dsp::IIR::Filter.

I get that the dsp version was added later, but it seems tied to a different paradigm of signal processing (the ProcessorChain approach as described in the Intro to DSP tutorial).

I’m just at the point of trying out JUCE’s built-in filters to replace some custom biquad implementations I’ve been using. My processBlock loop is running one sample at a time in the current project, so the shift towards the juce_dsp approach seemed, at first blush, like it would require a bunch more code rewriting that just swapping out which filter classes were being called. But maybe I totally got the wrong impression about that.

I think you don’t have to use the ProcessorChain etc. It is a paradigm that lets the compiler optimise very well as opposed to writing dynamic processing chains.

But I think, you can also use the dsp::IIR::Filter. It has a processSample() method, that processes one sample of one channel.

I thing I would not start using the old IIRFilter class, unless there are restrictions, that don’t allow using the dsp module, but that is certainly a matter of taste. (I am also not 100% friend with the new style, but I think it’s worth diving into).

I’d be into trying out the newer dsp::IIR::Filter option, because of its advantages, and (for now anyways) continuing to process sample-at-a-time.

This caveat gives me pause, however…

Moreover, you might need the function snapToZero after a few calls to avoid potential denormalisation issues.

The word “might” in particular - it makes it sound like some unknown factor might be introduced, and I don’t want to open a new can of worms at this point in the process.

EDIT: Poked around a bit and found this discussion re:snapToZero