Crash between AudioSessionHolder and MessageQueue::wakeUp when switching from loudspeakers to Bluetooth headphone on iOS


#1

Hi there,

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:

  1. Run the app

  2. Suspend the app

  3. Plug the Bluetooth headphone

  4. 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?

Thank you so much!


#2

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.


#3

I confirm this is is not only due to the Bluetooth headphone. It will also crash (more randomly) if you plug something into the 3.5mm socket.

Regarding JUCE’s example applications, our team will provide you further information as soon as they can.

To me it sounds like the problem lays on our side anyway and not on JUCE.


#4

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

  1. Open the Synthesizers tab of Juce Demos
  2. 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:


#5

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?


#6

Hi @t0m

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?


#7

OK we can confirm that the route change callback handling works seamlessly on the develop branch.

Any release date for this fix foreseeable on your side?
It goes without saying that for us the sooner the better. :slight_smile:


#8

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.


#9

Ok, thank for the update, sad to hear. We take this “relatively soon” as granted though :wink:

Btw, is there any public roadmap for JUCE 5 uploaded somewhere?


#10

No public roadmap I’m afraid.

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.