Does parameterValueChanged() need to be real-time safe?

Audio Plugins
1

According to the documentation of parameterValueChanged():

Receives a callback when a parameter has been changed.
IMPORTANT NOTE: This will be called synchronously when a parameter changes, and many audio processors will change their parameter during their audio callback. This means that not only has your handler code got to be completely thread-safe, but it’s also got to be VERY fast, and avoid blocking. If you need to handle this event on your message thread, use this callback to trigger an AsyncUpdater or ChangeBroadcaster which you can respond to on the message thread.

I am not sure about the meaning of audio callback here. If parameterValueChanged() is called from the audio thread, should I ensure the handler is real-time safe: no system call, no allocation/deallocation, etc?

2

Yes, parameterValueChanged should be realtime-safe. For reacting to parameter changes in the GUI, I use a simple helper that dispatches an async call from the parameterValueChanged callback.

1 Like
3

Currently I am using locks in my IIR filters (just like what JUCE IIRFilterBase does) to ensure the thread safety of my coefficients (when users change freq, gain, etc). I have watched two great talks recently.

And it seems that using CAS exchange and RCU are most suitable methods of updating coefficients. However, although they are thread-safe, they both have to allocate/deallocate on the thread which updates the coefficients. Therefore I may have to dispatches an async call as you suggested.

I will think more carefully about this :slight_smile: