fix: audio-mix and stop/start races in both publishers - #32
Merged
Conversation
Two pre-existing robustness gaps shared by RTMPPublisher and SessionPublisher, surfaced by the issue #20 resilience review. Fixed in both via the shared layer. 1. App-audio mix went permanently silent if the mic route was dead from go-live. HaishinKit renders the multitrack mix only when the MAIN track (mic, track 0) appends; the mic-stall failover only promoted app audio to the main track once the mic had appended at least once (`lastMicAppendAt > 0`), so a mic dead from the start never promoted and the whole mix — app audio included — stayed silent forever. MicStallEvaluator now measures mic silence from `startedAt` (go-live) when the mic has never appeared, so a dead-from-start route still promotes app audio once the grace window passes. The previously-working stall path is byte-for-byte unchanged (micReference == lastMicAppendAt when > 0). 2. stop() during start()'s pre-`isRunning` setup leaked long-lived tasks. Both publishers ran their setup awaits (factory/mixer setup + startRunning) before setting isRunning and spawning the path-supervisor / watchdog / frame-repeat tasks; a stop() interleaving there early-returned via `guard isRunning`, then start() resumed and spawned tasks it could never cancel (leaving a 2s watchdog timer waking forever and the mixer running). Added a `guard !userInitiatedStop` bail-out after mixer.startRunning in both, plus a second re-check in RTMP after the two status awaits (a narrower window Session doesn't have) so the supervisors/watchdog are never spawned post-teardown. RTMP's normal go-live path is unchanged (both guards fire only on a concurrent stop). Reviewed adversarially. StreamCore: 99 tests pass (+3 mic-stall cases); full app builds against the iOS 27 SDK. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Two pre-existing robustness gaps shared by
RTMPPublisherandSessionPublisher, surfaced by the issue #20 resilience review (they were out of scope there — pre-existing in both, not #20 regressions). Fixed in both via the shared layer; RTMP's normal go-live path is unchanged (both guards fire only on a concurrent stop).1. App-audio mix silent if the mic is dead from go-live
HaishinKit renders the multitrack mix only when the MAIN track (mic, track 0) appends. The mic-stall failover promoted app audio (track 1) to main only after the mic had appended at least once (
lastMicAppendAt > 0) — so a mic dead from the start never promoted, and the whole mix (app audio included) stayed silent forever.MicStallEvaluator.shouldPromoteAppnow takesstartedAtand measures mic silence from go-live when the mic has never appeared (micReference = lastMicAppendAt > 0 ? lastMicAppendAt : startedAt). The previously-working stall path is byte-for-byte unchanged.2. stop() during start()'s pre-
isRunningsetup leaked tasksBoth publishers ran setup awaits (factory/mixer setup +
startRunning) beforeisRunning = trueand before spawning the path-supervisor / watchdog / frame-repeat tasks. Astop()interleaving there early-returned viaguard isRunning, thenstart()resumed and spawned tasks it could never cancel — a 2s watchdog timer waking forever + the mixer left running.Added
guard !userInitiatedStop { await mixer.stopRunning(); return }aftermixer.startRunning()in both publishers, plus a second re-check in RTMP after its twoawait connection.status/await stream.statuscalls (a narrower window Session doesn't have).Verification
🤖 Generated with Claude Code