Getting back audio after phone call on iOS and SDL 2.0.5

Hi, I’m facing the problem with getting back audio after a phone call. The source code says that it’s handled using the audio session interruption notification (function update_audio_session() in SDL_coreaudio.m). I debugged this piece of code and the listener is called which in turn calls interruption_end(). However, AudioQueueStart() returns 561015905 and the audio is not getting back. Is there anything more I have to do (like loading sounds and music again) or the audio should get back automatically? I play sound and music using SDL_mixer 2.0.0. I’m testing it on an iPhone4S with iOS 9.3.2. Thanks in advance!

We are also having this problem.

We use OpenAL for audio, and it looks like we need to suspend the AL context when audio is interrupted, then restore the context when it is resumed.

I wonder if we should try and create our own iOS app delegate and listener, or if SDL should dispatch audio suspend/resume events, such as a new SDL_AUDIODEVICESUSPENDED and SDL_AUDIODEVICERESUMED

Having an event would help a lot for handling this nicely

Via , code 561015905 corresponds to this:

The documentation says: “This error type can occur if the app’s Information property list does not permit audio use, or if the app is in the background and using a category which does not allow background audio.”

You don’t need a custom AppDelegate to get audio interruption events in non-SDL_audio code, you just need to register a NSNotificationCenter listener for AVAudioSessionInterruptionNotification. (No SDL-related calls will be involved at all.)

Alternatively, are SDL’s existing event callback notifications
sufficient to handle this case? Particularly:
(See SDL_SetEventFilter() and make sure you implement the callback.)

I spent many early iPhone years fighting with AudioSession
interruptions and OpenAL in particular, filing lots of Apple radars.
There were a lot of nasty bugs in Apple’s frameworks for this case. I
haven’t had to deal with this problem in several years now, so I hoped
everything now just kind of worked. And I kind of hoped it all now
worked correctly with those two event notifications.

Would you please try adding your suspend/resume code on those event
callbacks and see it that fixes your problem? (Also, try invoking Siri
instead of a phone call to make sure that works too. The last bug I
dealt with this involved Siri basically triggering the same
interruption requirements as a phone call, but the Apple frameworks
internally didn’t do exactly the same thing which led to a nasty bug.
I believed they fixed it, but it’s a good test that can be tried
easier than a phone call.)

If not, you can do what Alex said. But I do think if the former
doesn’t work, we should propose/add the AudioSession notification to
the event filter callbacks because this is important platform system
level information that is needed and in my opinion the kind of thing
SDL is intended to help with.


Guys, does this work for you with latest SDL? It doesn’t for me.
I fixed this by closing and re-opening the audio device (and commenting the sdl interrupt code).
It seems you have to re-create the audio queue when this happens, details bellow:

  • Technical Q&A QA1558
  • Audio Queue – Handling Playback Interruptions
  • Q: Do I need to recreate my Audio Queue after receiving an interruption if I
  • want to continue playback after the interruption?
  • A: Yes. Currently to support Audio Queue playback though an interruption
  • event, applications need to dispose of the currently playing Audio Queue
  • object (by calling AudioQueueDispose) when the
  • AudioSessionInterruptionListener receives a kAudioSessionStartInterruption
  • notification.
  • Once the interruption is over and the AudioSessionInterruptionListener
  • receives the kAudioSessionEndInterruption notification, a new Audio Queue
  • object will need to be created and started.
  • Applications should save and restore any necessary state (eg. audio frame
  • number) required to pick up playback from the point of interruption.


@JaZzBrE could you elaborate on your fix? I’ve been poking at the code myself but so far my only achievement has been to kill the audio permanently.

I just Close the device on Pause and Open it again on Resume.
Nothing else worked reliably.