Audio Session Interruptions#1020
Open
pblazej wants to merge 3 commits into
Open
Conversation
Closes #1011 — audio loss after a system interruption (cellular call, alarm, Siri, FaceTime, etc.). Adds an LKRTCAudioSessionDelegate adapter that listens for interruption-end and externally-driven route-change events (.categoryChange, .routeConfigurationChange). On each, re-applies the current category/mode/options via the existing selectConfiguration helper. WebRTC re-activates the session on these events but does not re-apply our configuration; iOS can leave the session in a state different from what we configured. Also calls overrideOutputAudioPort as a workaround for a VPIO low-volume regression where audio comes back inaudibly quiet after resume; toggling the output port forces a fresh route selection that picks up the correct gain. No-op when isAutomaticConfigurationEnabled = false (e.g., CallKit apps that manage the session themselves), so this does not interfere with the documented CallKit integration pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reflects the behavior shipped in this branch — re-apply of category, mode, and options on interruption-end and externally-driven category-change events. Notes that the re-apply is skipped when isAutomaticConfigurationEnabled is false (CallKit pattern). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Tested basic cases like phone calls, AirPods, route changes, etc. Let's try to break it ⚒️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds interruption and route-change recovery for the iOS audio session. Closes #886 (audio not resuming after a system interruption — cellular calls, alarms, Siri, FaceTime).
LKRTCAudioSessionDelegateadapter re-applies the active category, mode, and options on:audioSessionDidEndInterruptionwithshouldResumeSession=true— iOS re-activates the session after an interruption but does not restore the configuration we set.audioSessionDidChangeRoutewith.categoryChange/.routeConfigurationChange— externally-driven configuration mutations (CallKit activation, system audio takeover).overrideOutputAudioPortreasserted on resume for.playAndRecord— Apple's documented workaround for a VPIO low-volume regression where audio comes back inaudibly quiet after interruption-end.isAutomaticConfigurationEnabled = false(CallKit apps that driveAVAudioSessionthemselves viaCXProviderDelegate), so this does not interfere with the documented CallKit integration pattern.selectConfiguration(state:)from Audio Session Defaults #1019, so resume picks the same category as initial activation (sticky bit, permission gate, etc.).Depends on #1019; merge base switches to
mainonce that lands.