User guide

There is no guarantee that a begin interruption will have an end interruption. Your app needs to be aware of

switching to a foreground running state or the user pressing a play button. In either case, determine whether

your app should reactivate its audio session.

OpenAL and Audio Interruptions

When using OpenAL for audio playback, implement an interruption listener callback function, as you do when

using Audio Queue Services. However, your interruption code must additionally manage the OpenAL context.

Upon interruption, set the OpenAL context to NULL. After the interruption ends, set the context to its prior

state.

Using the AVAudioPlayer Class to Handle Audio Interruptions

The AVAudioPlayer class provides its own interruption delegate methods, described in AVAudioPlayerDelegate

Protocol Reference. Likewise, the AVAudioRecorder class provides its own interruption delegate methods,

described in AVAudioRecorderDelegate Protocol Reference. You use similar approaches for the two classes.

When your interruption-started delegate gets called, your audio player is already paused and your audio session

is already deactivated. You can provide an implementation such as that shown in Listing 3-1.

Listing 3-1 An interruption-started delegate method for an audio player

- (void) audioPlayerBeginInterruption: (AVAudioPlayer *) player {

if (playing) {

playing = NO;

interruptedOnPlayback = YES;

[self updateUserInterface];

}

After checking to ensure that the audio player was indeed playing when the interruption arrived, this method

updates your app’s state and then updates the user interface. (The system automatically pauses the audio

player.)

If a user ignores a phone call, the system automatically reactivates your audio session and your

interruption-ended delegate method gets invoked. Listing 3-2 shows a simple implementation of this method.

Responding to Interruptions

OpenAL and Audio Interruptions