Making sense of AVAudioSession interruption notifications

Question

Created Mar ’25

Replies 2

Boosts 0

Participants 2

I have an app under development - demo here - https://youtu.be/VbAfUk_eYl0?si=s6EDBx-4G6P_QbZO - which is sort of an audio player for airdropped files - something useful to musicians who dump work in progress to their phone, make notes, revise and update.

I've been testing my handling of audio session interruption notifications, but seems to be a lot of inconsistency in how, when and why iOS delivers them, and I'm wondering if there is some rhyme or reason to it that I'm just not detecting.

For example, I am playing a song in my app. Switch to Apple Music and start playing a song there. My app gets an interruption began notification - this is consistent.

Switch back to my app, and about half the time, I will get an interruption ended notification (coupled often with a blast of the tail of whatever audio buffer was partially played when the interruption started, even though the engine was stopped - and followed by call to my AVAudioPlayerNodeCompletionCallback - is there some way to avoid this?). Half the time I don't get an interruption ended notification; my app can (as expected) end the interruption by activating the AVAudioSession and playing something.

I have not been able to determine any pattern to this behavior, other than that if my app started playing using AVAudioPlayerNode.scheduleSegment rather than scheduleFile I think the notification will be consistently delivered on app activation rather than when I activate the session programmatically.

I would like my app to behave deterministically, and would appreciate any help in deciphering what causes the inconsistent behavior in notifications from iOS.

Boost

Answer 1

Engineer OP

Apple

Mar ’25

Hello @timboudreau, thank you for your post. In general, there is no guarantee that an app will receive an interrupted ended notification.

Besides the Music app, there are many other causes for interruption. In particular, I would recommend testing with phone calls and route changes, such as plugging and unplugging headphones (please see Responding to audio route changes), so that your app behaves consistently.

In rare circumstances, the media server can get reset, so it is also important to handle the mediaServicesWereResetNotification and reconstruct your AVFoundation objects.

0

Answer 2

timboudreau OP

Mar ’25

Yes, I have am testing for all of the above.

The problem is not that I'm getting an interrupted ended notification (I've noticed that the end of a phone call often fails to result in one).

The problem is that I am getting an interrupted ended notification when it is inappropriate.

If I am playing music in my app, switch to Apple Music and play something there, and simply switch back to my app being the active one with Apple Music still playing, I should not get an interruption ended notification.

The problem is that about half the time I do, and there seems to be no pattern to it. There is no path in my own code by which becoming the active application could also activate the audio session, so it seems this really is a spurious notification iOS sends on its own.

Fundamentally, it would be rude for my app to hijack the audio session back simply because it became the focused app, when another app is still playing.

I would like to avoid that, but I can't see any obvious way to ignore interruption-ended notifications sent by the OS by mistake, without also ignoring ones I really should process.

0