forked from unom/punktfunk
enricobuehler
5ca0dfdcd2
Field report, with a competitor cited doing it right: connecting to a host PAUSED the user's Apple Music, and resuming Music mid-stream silenced the stream's audio for good. Both are one defect — the audio session was EXCLUSIVE. Activating it evicted whoever was playing (the pause at connect), and Music's resume evicted us right back; iOS stops the engines on that interruption and restarts nothing, so the stream stayed silent until reconnect. `.mixWithOthers` on every category path (playAndRecord, playback, tvOS) is the heart of it: a mixable session interrupts nobody at activation and is not interrupted by another app's mixable playback — game audio rides over the playlist, the way a console does it. The trade is that a mixable session is nobody's Now Playing app, so the lock screen keeps showing the music. For a game stream that is the correct reading. The other half is `installInterruptionObserver`: interruptions still exist for a mixable session — a phone call, Siri, an app claiming a NON-mixable session of its own — and ending one restarts nothing by itself. On `.ended` the observer re-runs the full activation (an interruption can drop the category, and the earpiece steer is per-route) and revives the engines through the same conservative `reviveStoppedEngines` the route-change and media-reset observers already use — unconditionally, not only on the `.shouldResume` hint: a live stream is the one case where the user's intent to keep hearing it is not in doubt, and the revive already declines when playback never went down. The teardown's `.notifyOthersOnDeactivation` stays as a courtesy for the edge where an old exclusive install interrupted something; a mixable session has nobody to notify. macOS build (session paths are #if'd out there), tvOS typecheck, 284 tests.