Stutter due to locking when creating AudioProcessorEditor

It seems this commit:

could lead to audio stutter drop-out.

I have yet to test it on a simple plug-in but on release builds of one of the products I work this cause a regression.
Opening plug-in editor for VST3 or AU on Ableton Live 10.1 causes audio drop-outs.

p.s - funny anecdote, the commit starts with bad :wink:

1 Like

We also have customers that report unresponsiveness. UI doesn’t open or takes several minutes etc. Maybe it’s caused by a similar issue? These reports are all relatively new.

You can pretty much test it in-house.

  1. built with/without this commit.
  2. run Ableton Live 10.1 with AU or VST3 instance of your product
  3. create a midi clip so you’re plug-in would make a sound
  4. close/re-open editor of that instance.

On my work-at-home MBP 13" mid-2018 this makes clicks/pops.

This is the thread that lead to that commit for some context:

It’s hard to see how removing the callback lock from the editor creation/destruction would cause audio dropouts as now there is a separate critical section to lock around access to the active editor which isn’t used around the processBlock calls. Are you perhaps taking the callback lock somewhere in your plug-in via AudioProcessor::getCallbackLock()?

Are you able to put together a simple example which reproduces this? I’ve taken the audio plug-in template and modified it to output a continuous sine wave and I can’t hear any audio dropouts when closing/opening the editor in Live 10.1 (VST3, AU or VST).

@reFX - are you using custom OpenGL context in your plug-in?
I’m trying to make a simple reproducible example.

@ed95 I’m continuing this on the relevant thread above. please close this discussion.

sorry and thanks! stay safe.

Sorry for the delay. Yes, we use an OpenGL context, so Juce renders faster on Windows. Not sure what you mean with “custom”. We don’t create one with our own shaders etc, just a standard OpenGL context we then attach to the editor, so all Juce components render faster.

I’ve continued this on the relevant commit thread. In our case I’ve looked into possible locks on the audio thread. Eventually it was the change of adding lock to getting the editor. (we’ve used it to determine if we need to process some analysis code).