Understanding Lock in Audio Thread

[daniel]

@Qfactor

As a result I’m going to assume that hosts normally update parameters from the message thread because this is where most plugins update their parameters.

On the contrary.
Host automation has to be in sync with the audio, hence parameters are set immediately before each processBlock() call. Some have a bespoke thread, but usually it is the audio thread.
It has to be that way, because the message thread would be way too slow in an offline bounce situation.

The message thread comes into play, when the user changes the parameter from the plugin editor. This can only occur in a real time situation, and it cannot be avoided that the GUI reaction is not synchronised with the audio on a sample level.

@Qfactor

So probably it is not a good idea to update an automatable parameter (and call setValueNotifyingHost) from the audio thread.

This is an ongoing discussion and afaik there is no proper solution (I haven’t read the proposal of the last post):

Calling setValueNotifyingHost() from processBlock()

Nope, that definitely isn’t safe, I’m afraid. Just because you haven’t heard of any problems doesn’t mean it’s safe. You’ve no idea what the host will do when you invoke that call, but it’s very likely that some of them will allocate memory or post a message, which will occasionally cause problems depending on what else the host is doing at a particular moment. The only safe way to send events from your process method is to have your own lock-free fifo to post events which you later pick up i…