AudioUnit AUv3 extension crashes

Audio Plugins
1

Hello,

I tried to update Projucer version to v4.3.0 and I found very strange issues.
AudioUnit Standalone is working fine, but AUv3 extension crashes when I try to load it by using GarageBand or Plugin Host of your example.
It crashes in deliverNextMessage function of “juce_osx_MessageQueue”.
I tried to find what the reason is but couldn’t.

It worked fine with Projucer v.4.1.0.
So finally I downgrade Projucer version to 4.2.4 and it worked also fine.

And one more thing, I can find Juce library v4.1.0 on GitHub, but I can’t find Projucer executable binary file from anywhere. When I want to get the previous version of Projucer, how can I do that?

Best regards.

2

Same here…Version 4.3 yields broken AUv3 on iOS.

3

Hmm I can’t seem to re-produce this on iOS (see screenshots below). Which plug-in are you trying to run?

Screen Shot 2016-11-30 at 09.46.26.png432×702 40.9 KB
Screen Shot 2016-11-30 at 09.46.34.png432×702 34.2 KB

4

You seem to be trying this on osx? Garageband does not support AUv3 on OS X so I don’t know how you are testing this. Maybe you are loading the AUv2 version.

The plugin host does support AUv3 on OS X and works fine for the AUv3Synth example in the JUCE/examples folder. What Plug-in are you trying to get working?

5

Hey @hasan_tata Can you verify this?

6

No…We are using GarageBand for iOS. When we compile AUv3 using Juce 4.3.0 We get audio extension errors. When we downgrade to 4.2.4 Everything seems to work fine.

7

Can you re-produce this with the JUCE example plug-ins (JUCE/examples/audio demo plugin/, JUCE/examples/AUv3Synth, JUCE/examples/PluginSamples)? That would help me re-produce this.

8

Those examples work fine. But my plugin not. Do I have to change some logic with message threading with new Juce? I am also running GarageBand on iOS with iPad 4 device. Plugin Host also shows error as well. Really strange…

9

Do you think you can send me a stripped down version of your plug-in which definitely reproduces the problem?

10

Just a head’s up: if your plug-in was using Projucer’s channel configuration field, then a commit that I just pushed to develop may have fixed a bug in the AUv3 wrapper.

1 Like
11

Hey @hasan_tata Did you submit the code?

12

I’ve also stumbled into this one. I get a crash when closing the project and then re-open it again. It seems like GB destroys the processor instance and keeps the editor instance alive for some reason (I access the processor from the editor in a timer callback to synchronise parameters). This behaviour is new since iOS 10 though.

I tried a quite dirty workaround setting a flag in the processor destructor (and checking it from the timer callback in the editor) and that makes the crashing less frequent, but still happens now and then though since the deletion probably happens on a different thread. Haven’t tried any locks etc yet…

Edit: Just tried by adding a lock on the timer and in the processor destructor and it seem to work perfect.

13

Hi Sundhage,

I have been reported a similar crash so I’m very interested in your workaround.

Does the editor ultimately get destroyed?

Thanks for any additional info.

Mariano

14

The editor gets destroyed right after the processor (probably from some other thread). Here’s how my test-fix looks like. It could certainly be better implemented, just haven’t had the time to do so…

In the processor (.h-file)

void* editor_m;
bool editorIsPresent_m;
CriticalSection* exitLock_m;
void setEditorPresent(bool isPresent, CriticalSection* exitLock)
{
    exitLock_m = exitLock;
    editorIsPresent_m = isPresent;
}

In the processor constructor:

exitLock_m = nullptr;
editorIsPresent_m = false;

In the processor destructor:

if (exitLock_m) { exitLock_m->enter(); }
if (editorIsPresent_m) { ((TinesAudioProcessorEditor*)editor_m)->processorIsDeleted(); }
if (exitLock_m) { exitLock_m->exit(); }

In editor (.h)

bool hasProcessor_m;
CriticalSection exitLock;

void processorIsDeleted()
{
    hasProcessor_m = false;
}

In editor constructor

hasProcessor_m = true;
p.setEditorPresent(true, &exitLock);

In editor destructor

if (hasProcessor_m) processor.setEditorPresent(false, nullptr);

In the timer callback

exitLock.enter();
if (!hasProcessor_m)
{
    exitLock.exit();
    return;
}

// do any communication with the processor…

exitLock.exit();

Edit: forgot one thing. In the processors createEditor() i save the reference to editor_m:

AudioProcessorEditor* PadsAudioProcessor::createEditor()
{
PadsAudioProcessorEditor* editor = new PadsAudioProcessorEditor (this);
editor_m = (void)editor;
return editor;
}

15

Thanks, this further clarifies the issue.

I assume we can’t force deletion of the editor from the processor destructor; haven’t seen anything for that in the API. It’s a pity that iOS 10 is not doing it in the right order.

Have you considered calling a custom editor method like disable() in the processor constructor (of course, only if getActiveEditor() is not null) that would set a kind of disabled flag that would stop any interaction with the processor? Would that work?

16

Ah, didn’t know about getActiveEditor(), should be used instead of my juggling with editor_m.

No, the editor gets deleted by the host. It’s just Garageband on iOS 10 that deletes the processor first, most likely from some other thread. But if the locks are in place, and the processor tells the editor that it got deleted it’ll work. I’ve tested my plugins in AUM, Cubasis and Garageband with my fix, and haven’t had any issues yet…

17

I have tried using getActiveEditor() to avoid keeping a separate reference to the editor, but I still get the problem. Don’t know how GB handles this but it seems to mess up the underlying stuff.

So finally I have done as you suggested and it works perfectly. Thanks a lot.

18

It’s really weird… when debugging this and setting a breakpoint in the editor destructor, it never gets called. Still, no leaks… must be magic. I can confirm that getActiveEditor() doesn’t do the trick, you need to keep the pointer from when the editor is being created.

19

This thing also occurs on AUM on iOS 10.x and an upcoming AUv3 (significant) host that I’m not sure I can tell about right now… I’ve talked a bit with the AUM dev, and it looks like this is something that’s happening inside CoreAudio. I’ve got no details around it, but I guess most AUv3-builds using Juce will be affected. At least if the editor is accessing the processor instance in any way.

To reproduce in AUM: Add the AUv3-plugin, remove it and add it again. If there’s s timer callback in the editor accessing the processor instance there will be a crash (the processor gets deleted before the editor).

20

Thanks for reporting this. I’ll investigate…