iOS Standalone crashes with external audio interface

This is only happening with the standalone, AUv3 works fine in several hosts.
If I run the standalone with an audio interface connected to the iPad, the screen goes black, and after a few seconds, the app exits. I found a few crashes in the Analytics section but there are no symbols so I have no clue how to use these.
However, if I run the standalone without the audio interface connected and then I connect it, it works. It takes a few seconds to load, but no crashes.
I confirmed this with a few of our products on two different iPads with two different audio interfaces.
Any clue?

After checking this thread, I’ve tried the same thing and it seems to be working.
Basically forcing availableSampleRates to only have 48000. I’ll do more tests, but this seems like a very big issue that should not happen.

Ok so, I think that the way updateAvailableSampleRates() in juce_ios_Audio tests all the sample rates is the real issue rather than a specific sample rate.
I’ve changed the sample rate logic to this:

        Array<double> sampleRatesToTest { 22050, 44100, 48000, 88200, 96000, 192000 };
        for (auto rate : sampleRatesToTest)
            const double supportedRate = trySampleRate (rate);
            JUCE_IOS_AUDIO_LOG ("Trying a sample rate of " << rate << ", got " << supportedRate);
            availableSampleRates.addIfNotAlreadyThere (supportedRate);
            rate = jmax (rate, supportedRate);

seems to be working in my case. Also, worth noting, it took several seconds (even up to 10) before crashing, now it loads really quickly.

Again, the issue happens only when there’s an audio interface connected, but I have no idea how to debug an iPad with an audio interface. I tried to use a dongle to connect 2 usb-c cables and XCode doesn’t see the iPad.

1 Like

Yes we just ran into the same or related issue. For example I have a Focurite Scarlett 2i6 connected via USB. Starting a standalone app causes continuous clicking for 10s of seconds as the card is activated/deactivated while testing if it can handle the requested rate. If I’m not debugging then the app gets killed or crashes. I suspect killed as it’s taking too long to come up. If debugging it doesn’t crash or get killed as I think iOS knows it’s being debugged.

Even if it didn’t crash/get killed the continuous clicking is a problem.

1 Like

Have you investigated JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES at all? There’s some more info in this thread:

Essentially, there doesn’t seem to be an API for an interface to advertise its supported rates on iOS. Instead, the app has to query the rates that it wants to use. By setting JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES, you can limit the number of different samle rates that are tested.

The crash seems like a problem that would be good to fix, but it’s likely to be difficult to repro without hardware that causes the problem. Have you tested any other devices, and if so, do they behave in the same way?

1 Like

Interesting. Thank you. Will look into it further and try out with more external hardware and report back.

OK, in addition to the Focusrite I tested with an M-Audio M-Track Solo and no clicks so I think it’s fair to say this is hardware specific.
The Solo doesn’t support as many rates so comes up a lot faster.
What we might have to do is limit to some common explicit rates like AUM does but we could offer the user advanced settings where they can probe for more.