Avoid concurrent main-thread callbacks with AU Logic Pro

[SamWindell]

Logic Pro using an AU wrapped CLAP is calling GetParameterInfo from the audio thread (when I query the name of the thread it returns com.apple.audio...).

In GetParameterInfo, the wrapper calls the CLAP's params.get_value function - main thread only.

It's only doing this to set a flag though, we could avoid this by querying this once earlier on rather than in the GetParameterInfo callback

clap-wrapper/src/wrapasauv2.cpp

Lines 457 to 467 in 5ba58f1

	// we can't get the value since we are not in the audio thread
	auto guarantee_mainthread = _plugin->AlwaysMainThread();
	double value;
	if (_plugin->_ext._params->get_value(_plugin->_plugin, info.id, &value))
	{
	char buf[200];
	if (_plugin->_ext._params->value_to_text(_plugin->_plugin, info.id, value, buf, sizeof(buf)))
	{
	flags |= kAudioUnitParameterFlag_HasName;
	}
	}

[baconpaul]

we can clearly at setup time use value_to_text with the default value indeed at setup time. (value_to_text is main thread only also iirc)

[SamWindell]

Just a little more info on this:

In my temporary fork I have commented out the code that calls get_value and value_to_text, and just always add the kAudioUnitParameterFlag_HasName flag instead. I've been using this for a few weeks now and the CLAP wrapper behaves correctly in Logic and Garageband: there are no long parallel 'main thread' calls.

[baconpaul]

Great! So it really does sound like thats the problem then?

[defiantnerd]

So actually, this is no problem at all since it just gathers rendered text strings for automation and generic view.

A plugin should be consistent enough to handle this.

It is also a possibility to declare this "must be thread safe", isn't it?

[SamWindell]

I still think there's a problem here, and an easy fix.

Here are the facts:

1. Logic Pro and Garage Band call AU GetParameterInfo from the audio thread.
2. Within GetParameterInfo, clap-wrapper is calling the CLAP's get_value and value_to_text: these 2 functions are main-thread according to CLAP spec.
3. The result is that the CLAP can receive parallel callbacks from functions that are meant to be main-thread according the CLAP spec.

So my solution: don't call get_value or value_to_text from inside GetParameterInfo. Instead it can be cached earlier, or just assume always kAudioUnitParameterFlag_HasName.

You could claim Logic/Garageband are broken for calling GetParameterInfo from the audio thread. But who's so say what counts as 'broken' for AU? As far as I know, there is no clear spec on what threads are used for what.

This fix for me helps a lot of cases. But as far as I'm concerned we're not out of the woods with regards to inconsistencies regarding CLAP vs VST3/AU threading models. I'm still getting occasional strange things happening.

[defiantnerd]

Actually this line:
if (_plugin->_ext._params->get_value(_plugin->_plugin, info.id, &value))
is only called to get a valid value that can be thrown against the conversion function. We do have other valid values, the default value, min and max. This is part of the parameter definition and can be called anyway. We could just use them. This way get_value() is not being called anymore and all should be fine.

Do you agree?

[SamWindell]

Yes, I think I know what you mean. As Paul suggested above we should just pre-compute the flag when the plugin initialises. That would do the job perfectly.

[defiantnerd]

Oh - I missed Pauls comment.

Yeah, I'll put up a PR and we should make next to main soon.