Routing changes, hopefully the last time


#1

It feels like an endless story but it seems iOS users want us to nail the exact standard behavior of other iOS apps like the stock music app. So here we go again…

Imagine the following use case: Listen to app with headphones. Pull headphones.

The music app pauses playback in that case. A JUCE app continue with playback using the iPhone/iPad speaker.

There are more combinations possible with bluetooth headset and headphones plugged in and out but everything seems to come down to the following simple change in juce_ios_Audio.cpp, routingChanged method:

[code]if (routeChangeReason == kAudioSessionRouteChangeReason_OldDeviceUnavailable)
{
{
const ScopedLock sl (callbackLock);

	if (callback != nullptr)
		callback->audioDeviceError ("iOS routing changed, old device unavailable");
}

// fixAudioRouteIfSetToReceiver();

}
[/code]

This would make a JUCE app behave exactly the same as regular iOS apps like the music app. What do you think, is it a good idea to make this change?

Patrick


#2

I’d give this a tentative “yes”, but would welcome other opinions too…


#3

FWIW: I have no interest in this as a dev, but as a user, I would absolutely prefer that patch.


#4

Well even with the patch, if you want the old behavior can’t you simply not pause on the routing change?


#5

Yes you could. It depends on what you are doing in the audioDeviceError callback. My implementation updates the ui to a paused state. Alternatively you could try to recover and continue playback on whatever output is available.


#6

Yes, I think this makes a lot of sense. Thanks!