Some people argue locking in the audio thread isn’t a problem, but as we all know, audio waits for nothing. Real-time music dsp’s strength is, well, being real-time. For prototyping and private projects it obviously isn’t a problem, but I would never do something like this in production code. I’ve seen audio stutters live on stage, and personally have experienced it myself live as well, due to a single plugin taking ‘liberties’.
[quote=“daniel, post:8, topic:20405”]
EDIT: I read a little in the sources, the processLock the filter uses guarantees that setting all coefficients for the filter is an atomic operation. But it is not synchronised with the critical section of the audio thread calling processBlock.I don’t know if this is a problem in practise, but I think the lock in updateCoefficients using the criticalSection of the audio thread is no bad idea… but I am happy to learn if I’m wrong…
[/quote]It is synchronized since the iir filter object acquires the same lock inside its own processing method.
You can easily swap a complex data structure atomically and without any associated cost perfectly safe and standard-compliant:
[quote=“jnicol, post:3, topic:20405”]
Thanks for the reply @mayae. I haven’t experienced zipper noise yet, but to avoid that possibility do you think it would be sufficient to recalculate the coefficients for each sample like so inside processBlock:
int blockSize = buffer.getNumSamples();
for ( int i = 0; i < blockSize; i++ )
{
// Recalculate coefficient and apply filter here
}
Are there any performance drawbacks to doing this, or a better method that I am unaware of?
[/quote]Yes, recalculating filter coefficients is not cheap compared to most other operations. To be pedantic, the problem with your approach is that it isn’t invariant of the host’s block size (ie. you get more zipper noise the higher the hardware latency is).
Most people implement some form of linear interpolation, while being vastly better, can still introduce varying amount of smoothing / discontinuities. Personally, for mastering and mixing purposes, I’ve found the only thing working well while also always sounding/producing the same output and / or approximating an automation signal to a convergent degree, is to integrate the control signals using some higher order lowpass filter and update the filter coefficients each sample.
So, it’s a tradeoff between processing time and determinism and quality - and remember, one you always can change at a later stage. If a plugin doesn’t support automation on filters, it would be extremely overkill to implement all of this, for instance.