Repository navigation
Audio drops out for remaining participants when others disconnect; selecting their source restores it #608
Description
Activity
Live recurrence, 2026-09-26 (#608)
Current installed-running app build
d23dc9d56b118e07171e4d13a270421450fd8965, 17 participants. Operator reports Courtney Goodin and Tony Mobley intermittently inaudible in CoreVideo Monitor while Tony remains audible to people in the regular Zoom client. Clicking an affected participant's multiview video into Preview restores hearing. Do not infer Zoom mute from this alone; Courtney was Zoom-unmuted during the captured failure.At 10:20:33 EDT, Courtney (Zoom user ID
16793600) was Zoom-unmuted, talking=true, Zoom audioLevel=78. CoreVideo's pre-fader, PCM-derivedaudioMixSession.participants[].inputRmsDbfswas −71.3 dBFS (inputPeakDbfs=−63.9, statussilent), while his CoreVideo channel was unmuted and he had a livemonrouting send. His source had ingested 31,732 audio packets;participant-audio-16793600-mixwas subscribed, generation 1, churn 0. Monitor underruns remained at cumulative 5 and realtime audio lost samples at 0.At 10:20:47 EDT, after the operator put Courtney in Preview, Zoom still showed him unmuted/talking at level 78 and the CoreVideo input rose to −22.7 dBFS (
inputPeakDbfs=−14.3, statuscleaning). The audio subscription was still subscribed, generation 1, churn 0. Video purpose becamepreviewwith video churn 0. This rules out a visible unsubscribe/resubscribe as the repair; the full Preview scene sync may still refresh another state. It also makes a monitor-endpoint underrun or output fader failure unlikely: the input PCM meter itself was near-silent before the click.Tony (
16797696) was also reported inaudible in CoreVideo while audible in normal Zoom. A pre-click snapshot had him Zoom-unmuted, CoreVideo channel unmuted and routed tomon, audio subscription active/generation 1/churn 0, but his Zoom talking flag was false and CoreVideo input was near-silent. That instant alone cannot prove a Tony-specific defect; he subsequently muted, so the 60-second telemetry trace was not a controlled speech sample.Relevant behavior:
PreviewMultiviewTilechanges the Preview solo route and triggersSyncActiveSceneAsync;ZoomSourceSetPolicyincludes Preview routes in the source set, but the audio UUID/purpose remainsparticipant-audio-<id>-mix. The next diagnostic must timestamp measured PCM level/sequence at the SDK one-way callback, engine SHM write, core SHM read, source-bus ingest, and pre-DSP mixer input across a natural recurrence. That will distinguish Zoom SDK raw-ISO silence from transport/ingest staleness and a full-sync side effect. Do not fix this by changing monitor buffers or by adding a global delay.Additional live recurrence at 10:23:33 EDT: Craig Macfarlane (
16796672) was Zoom-unmuted and talking (audioLevel=78), CoreVideo channel unmuted with sends tomaster/pgm-l/pgm-r/mon/stream, but pre-fader input measured only −52.7 dBFS and statussilent. The per-guest audio subscription remained active at generation 1/churn 0; monitor underruns stayed 5 and audio lost samples 0. Eight seconds later his input was −34.5 dBFS/statuscleaning, still with audio churn 0. The meeting useszoomAudioMode=perGuestIso;zoom-mixhas its own producing source (not routed in this mode). The operator also observed Tony inaudible in CoreVideo while others in regular Zoom heard him. Three guests in one meeting strengthen the shared per-guest raw-audio/ingest hypothesis; the exact stage that attenuates PCM is still unproven.Root cause isolated in the 2026-09-26 live meeting; PR #656 has the scoped fix and tests.
On the installed-running
d23dc9d5build, Craig (16796672) spent about nine seconds (10:31:59–10:32:08 EDT, 18 half-second samples) Zoom-unmuted while CoreVideo's mixer channel remained muted. In 16 samples Zoom marked him talking at level 78. Raw per-guest SHM PCM and CoreVideo's pre-mute input meter both showed audible signal during this interval. Audio subscription generation remained 1/churn 0; monitor underruns stayed 5 cumulative and lost samples 0. This supersedes my earlier tentative PCM-silence/Zoom-SDK hypothesis.The shell copies Zoom's source mute into the persistent core mixer mute during a production sync. Roster mute changes refresh the UI strip but do not send a new mixer command while applying snapshot patches. Putting the guest into Preview sends a full scene sync and refreshes that stale mute, explaining the operator's recovery action. PR #656 makes the core mixer mute follow only the operator strip; Zoom source mute stays visible separately. Current meeting is still on the old installed build, so the deployed live recurrence check remains open.
- added a commit that references this issue
on Sep 26, 2026
Reported behavior
Audio intermittently drops out for seemingly random remaining participants when other participants drop/disconnect. Selecting an affected participant's source appears to restore their audio.
Reported sequence
This is the user's observed pattern, not yet a confirmed deterministic reproduction.
Expected behavior
Participants leaving or disconnecting should not interrupt audio from remaining participants. Their audio should continue without requiring source selection.
Investigation
Check whether participant removal or roster changes invalidate audio routing, source bindings, or subscriptions for remaining participants, and whether source selection re-establishes that state. These are investigation leads, not confirmed causes.
Build/version, frequency, affected output paths, and diagnostic logs have not yet been captured.