Repository navigation
Re-activate the audio session on play(), so audio survives an interruption - #937
Merged
Merged
Conversation
Playback resumed after a phone call with picture and no sound, and only came back when the viewer left the player and resumed from the detail screen. The audio session was activated in exactly one place: `KSOptions.setAudioSession()`, called from the player's initialiser. iOS deactivates an app's audio session when it interrupts the app and when it suspends the process, so a call on a backgrounded player leaves the session inactive. Nothing activated it again, and AVPlayer renders picture perfectly well without an active audio session - which is precisely why the failure looked like a missing soundtrack rather than a broken player. Resuming from the detail screen built a new player, and its initialiser activated the session, which is why that appeared to fix it. Both engines resume through `play()`, so activating there covers every path: the automatic resume after an interruption, and the viewer pressing play afterwards - including the suspension case, which never delivers an `ended` event to recover from at all. `activateAudioSession()` deliberately leaves the category alone. Re-setting it on a live session can glitch the audio, and the category survives deactivation unchanged. Activating an already-active session is a no-op, so calling it on every play is safe.
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
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.
Playback resumed after a phone call with picture and no sound, and only came back when the viewer left the player and resumed from the detail screen.
The audio session is activated in exactly one place —
KSOptions.setAudioSession(), called from the player's initialiser. iOS deactivates an app's audio session when it interrupts the app and when it suspends the process, so a call against a backgrounded player leaves the session inactive with noendedevent to recover from.Nothing activated it again, and AVPlayer renders picture perfectly well without an active audio session — which is precisely why the failure looks like a missing soundtrack rather than a broken player. Building a new player activates the session again, which is why resuming from the detail screen appeared to fix it.
Both engines resume through
play(), so activating there covers every path: the automatic resume after an interruption, and the viewer pressing play afterwards — including the suspension case, which never delivers anendedevent at all.activateAudioSession()deliberately leaves the category alone. Re-setting it on a live session can glitch the audio, and the category survives deactivation unchanged. Activating an already-active session is a no-op, so calling this on every play is safe.Nothing is removed, and no existing behaviour changes: this only adds an activation where there was none.