Huge performance issue with AudioUnitPluginFormat::setParameter()

In AudioUnitPluginFormat class - there is the “setParameter()” function. In our tests - we found that rapid calls to this function start to buffer up somewhere resulting in the audio unit plugin lagging in response and ultimately stop producing sound.

This does not happen in VST versions of the plugin and is reproducible with ANY plugin. AU versions do have a problem, VST versions don’t.

Tracked it down to the following…
void setParameter (int index, float newValue) override
const ScopedLock sl (lock);

    if (audioUnit != nullptr)
        if (const ParamInfo* p = parameters[index])
            AudioUnitSetParameter (audioUnit, p->paramID, kAudioUnitScope_Global, 0,
                                   p->minValue + (p->maxValue - p->minValue) * newValue, 0);

            sendParameterChangeEvent (index);

As you can see - at the end of setting the parameter - a call is being made to “sendParameterChangeEvent()” presumably to notify any listeners about the change.
This call is what seems to be the culprit even if there are no listeners to parameter changes attached to that plugin.

The call cannot be just removed as any future listeners will then not get notified.does anyone know if there is any obvious performance issues here? Seems that this call wants to do something on the main thread, but it is unclear why is it taking so much CPU time even with no listeners.

Any suggestions are welcome.

Calling AUBase::PropertyChanged instead?

(as explained in this thread AUEventListenerNotify and property changes in Leopard

This seems to have been a false alarm. I apologize …

There was one callback registered for the AU version of a plugin and this particular plugin that we were testing with (VB3, AU version) does something unexpected.
Every time any parameter changes within that plugin - it send out parameter changed message for ALL parameters it has. So if one grabs the 9 drawbars and moves them up/down - it is generating 9xtotal_number_of_parameters which basically ends up in more than a thousand calls every time.

We thought this was happening with other plugins, but it seems it just this one for now. Thanks to anyone who responded…