We’re having a big crash when switching the audio device on the fly on iOS. This is seriously blocking our development so far and we wonder if we’re the only one experiencing this issue.
Here are the steps to reproduce:
Run the app
Suspend the app
Plug the Bluetooth headphone
Come back to the app
Current result: Juce will crash in MessageQueue::wakeUp when trying to call AudioSessionHandler::handleRouteChange
Dev Environment: We are using Juce 4.3.1 to release a sampler static library, there is no GUI involved (therefore I need to manually instantiate the MessageManager).
The static library is then integrated within a React Native environment on iOS.
Any idea what could cause this issue? Has anybody the same problem?
Does this happen with any of JUCE’s example applications? I suspect we would have noticed this before now, so it seems likely this issue is related to your usage of the MessageManager.
Does it have to be Bluetooth headphones? What happens if you plug something into the 3.5mm socket (if you’re lucky enough to have one)?
Could you provide a minimal working example? Dealing with handleRouteChange callbacks is a difficult problem, so I doubt we will be able to help much if we can’t reproduce the problem.
Hi @t0m, first of all very sorry about the late reply we had to put this on hold for a while.
So we’ve just gotten to trying to reproduce the crash with the Juce demo example and… it turns out we end up with a slightly different symptom but yet a very similar problem.
Basically when rerouting the audio output to a headphone intermittently, Juce will indefinitely hang when calling AudioComponentInstanceDispose(audioUnit) in iOSAudioIODevice::createAudioUnit
So it seems that, unlike in our case, the audio routing change message is posted in the main thread, but it will result in a deadlock when releasing the former audio component.
I have no idea how these two symptoms relate to each other but they look way too similar to me not to have a root cause in common. We can reproduce this on different iPhone models (5 to 7) and with different wireless/cable headphones.
How to reproduce?
It’s very easy to reproduce with a Bluetooth headphone (1 out of 3), more randomly with a 3.5mm socket (1 crash out of 10).
Conditions:
Get your hand on a Bluetooth headphone (it’s the future man!) and run the Juce Demos project
Open the Synthesizers tab of Juce Demos
Play around with the keyboard while connecting/disconnecting the external audio output
Current result:
After 1 to 3 attempts the app will hang
What to do now?
This is a major blocker for our release unfortunately, as we don’t want our users to experience a crash or a hang as soon as they plug their headphone.
How could we support you fix this bug?
Should we report these two bugs in your issue tracker?
Thank you so much!
Screenshot of the callstack stuck in a seemingly deadlock:
Since your previous post we’ve improved the iOS route change callback handling on the develop branch. Are you using the develop branch? If not, could you please see if this improves things?
I will ask my remote team to confirm it but at first sight I might have a good news!
I’ve just tried with the develop branch and it seems that the problem has been solved.
The Juce Demos doesn’t hang any longer and our app doesn’t crash.
Would you know when this fix will be released by any chance?
Unfortunately it’s not easy to patch the master branch with these changes, so you’ll have to wait for the next release. However, we’re currently preparing JUCE 5, which will have the fix included. Experience has shown that it’s almost always a bad idea to post firm dates for releases on the forum - but it should be relatively soon.
The current develop branch is very stable at the moment, and it’ll get merged into master when JUCE 5 launches - I’d suggest you start using it now if you want a swift migration to the new release.
