Multiple AUv3 instances on iPad Pro problem

MacOSX and iOS
1

We’re getting reports of host crashing and plugin unloading when using more than 4 to 6 instances of an AUv3 on iPad Pros (specifically the 12.9, but one user has recreated the issues on a 10.5.) There is a lengthy discussion on the AudioBus forums here:

Page 2 has the pertinent customer testing. I’ve been able to recreate a couple of these scenarios; due to the nature of AUv3s being sandboxed, I can’t really see what’s crashing, though. My working theory is that there’s some RAM issue.

So my question, before I go and buy a 12.9" iPad Pro, is whether anyone else has seen this, and if so, is it JUCE-related and is there a workaround?

2

Yes, we saw this as well and I did fix a few potential AUv3 crashes a while back (especially commit c430b03, but the following might also be interesting b86e133, 0365faf). Can you confirm that these commits are in your code?

3

We released a plug yesterday, Pumphouse, that is built with 5.1.1, and it exhibits the above-referenced issues, albeit not as severe as some of the 5.0.x releases. I’ll rebuild the earlier ones with 5.1.1 and see if that improves matters a bit.

4

Okay, I’ve done some more research and (against my better judgement) purchased a 12.9", and here’s what I’ve discovered:

If you instance multiple instances of a JUCE-built AUv3 without opening the GUI on each one, the plugins fail after 2-3 instances. This is only on the 12.9" iPad Pro and to a lesser extent on the 10.5" iPad Pro. (That is to say that you can generally open a couple more instances on the 10.5 than you can on the 12.9.) This has all the earmarks of a problem in the ViewController allocation. I’m going to try a couple things, but if anyone here has an idea of where to point a fix, I’d love to hear about it.

5

Repeatable test case on a 12.9 iPad Pro (with A10x CPU, latest model, purchased this morning, running 10.3.3). This is in any AUv3 host except Auria Pro:

  1. Build JuceDemoPlug for iOS AUv3 against JUCE 5.1.1

  2. Open host (I use AUM and AudioBus 3, but as I said, any except Auria Pro will work)

  3. Create 5-10 insert slots. Start adding JuceDemoPlug AUv3 instances without opening the UIs.

  4. At approximately 6 instances (I got to 8 a couple times) they’ll all redline and dump.

It seems to be dependent on the amount of RAM the UI itself needs. Our stuff has a ton of procedural drawing and SVGs and what-not, and failed much sooner, 2-4 instances.

6

Just a quick test. Does the JuceDemoPlug also crash when you don’t have a debugger attached. We have had reports from Apple themselves that there are a few issues when debugging an appex which can cause the AUv3 to crash. We’ve definitely seen this happen a few times.

7

Yeah, of course. I actually don’t even bother with the debugger with AUv3s, since they’re so unstable it’s almost useless, and aside from that, the results vary by host.

The above test case is a release build.

8

@JUCE
It would be a very useful addition, if you could integrate this:

void didReceiveMemoryWarning ()
{
    auto& processor = getAudioProcessor();
    processor.didReceiveMemoryWarning ();
}
...
- (void)didReceiveMemoryWarning
{
    cpp->didReceiveMemoryWarning ();
}

in juce_AUv3_Wrapper.mm

and this:

virtual void didReceiveMemoryWarning () {}

in juce_AudioProcessor.h

In any inherited AudioProcessor you can then react to “Out of Memory” situations in iOS.

I know, this is platform specific, but I see no other way to handle this properly. Unfortunately this means to patch JUCE standard components, which I don’t want to do…

What do you think?

1 Like
9

Seems more like something that should go into JUCEApplication or similar as any iOS app could get a memory warning. Obviously, an AUv3 does not have a JUCEApplication instance (although it is a process) so I’d have to think on how that would work. Maybe, the first time an AUv3 gets instantiated it should also create a JUCEApplication object…

10

Sounds reasonable. This seems to be a very good idea! I could test it, if you add something to the develop branch.

11

Cross linking this relevant post here:

I’m still working on implementing a suitable way to report the memory usage warning.

1 Like
12

Just an update on the AUv3 specific problem: the new version of AUM that went up yesterday has a solve for this, as does Beatmaker 3. On the host side, they just open the UI off screen when the plugin is instanced to keep the allocation happy.

There is no current solve on our side for it that I’m aware of.

13

Hi Fabian, did you already advance in regard to memory warnings and the JUCE Application object in the AudioProcessor?

14

No not yet, but we are investigating the issue. In general, it seems that the AUv3 memory limit is around 300 MB. Do you have a similar experience?

15

Hi Fabian, sorry for the late reply. I will further investigate this soon. My first tests showed, that the crash-limit for the whole sandboxed process including all instances of the plugin seems to be reached at around 300 MB on older devices and on newer devices a little bit later (>370). Measured with Instruments “Real Memory” (and Cubasis as host). This would roughly fit to your quotation. MemoryWarnings can come up much earlier (starting around 240 MB). Sometimes the limit can only be reached, if the AUv3 instances are loaded after another and not “at once” (e.g. if cubasis loads a song with more than one instance of the plug-in). Maybe this could be managed by a good internal loading mechanism.
I now search a good way to decide, if a new instance can be loaded, or a kind of dummy should opened instead (to not crash the already existing instances).

16

Yeah that sounds reasonable. Unfortunately there isn’t much that JUCE can do here for now. In NOISE Auv3 I think we will stop the user from loading certain samples if memory gets tight.

17
1 Like
18

:smiley: Thank you, Tom!
I’ll give it a try.