Denoise restart fallback hands LiveKit the raw mic as processedTrack, which later gets stopped #2

Closed
opened 2026-09-12 02:12:57 -04:00 by jared · 1 comment
Owner

Severity: high · Type: bug · Confidence: high

Location: src/lotus/lotusDenoiseProcessor.ts:181-188, src/lotus/lotusDenoise.ts:151

Problem

When restart() fails it sets this.processedTrack = opts.track — the raw MediaStreamTrack LiveKit owns as _mediaStreamTrack. LiveKit's internalStopProcessor() does this.processor.processedTrack?.stop() and then setMediaStreamTrack(this._mediaStreamTrack, true) (livekit-client 2.18.x, livekit-client.esm.mjs:19621). Since the two are now the same object, any later stopProcessor() — including the module's own teardown at lotusDenoise.ts:151, or a second setProcessor()stops the live microphone and then re-publishes the dead track. That is the A7 "mic dead after reconnect" class of bug the processor was written to fix, reintroduced on the degrade path.

How to trigger

Force one restart() failure (e.g. device switch while the denoise assets 404, or an AudioContext sample-rate mismatch), then leave the call / re-enter, or let anything call stopProcessor(). Mic is permanently silent for the rest of the session.

Suggested fix

On the fallback path set this.processedTrack = undefined (LiveKit then falls through to _mediaStreamTrack at livekit-client.esm.mjs:19141 and 19201), and never assign LiveKit-owned tracks to processedTrack.


Filed from the September 2026 audit (branch lotus).

**Severity:** high · **Type:** bug · **Confidence:** high **Location:** `src/lotus/lotusDenoiseProcessor.ts:181-188`, `src/lotus/lotusDenoise.ts:151` ### Problem When `restart()` fails it sets `this.processedTrack = opts.track` — the *raw* `MediaStreamTrack` LiveKit owns as `_mediaStreamTrack`. LiveKit's `internalStopProcessor()` does `this.processor.processedTrack?.stop()` and then `setMediaStreamTrack(this._mediaStreamTrack, true)` (livekit-client 2.18.x, `livekit-client.esm.mjs:19621`). Since the two are now the same object, any later `stopProcessor()` — including the module's own teardown at `lotusDenoise.ts:151`, or a second `setProcessor()` — **stops the live microphone** and then re-publishes the dead track. That is the A7 "mic dead after reconnect" class of bug the processor was written to fix, reintroduced on the degrade path. ### How to trigger Force one `restart()` failure (e.g. device switch while the denoise assets 404, or an `AudioContext` sample-rate mismatch), then leave the call / re-enter, or let anything call `stopProcessor()`. Mic is permanently silent for the rest of the session. ### Suggested fix On the fallback path set `this.processedTrack = undefined` (LiveKit then falls through to `_mediaStreamTrack` at `livekit-client.esm.mjs:19141` and `19201`), and never assign LiveKit-owned tracks to `processedTrack`. --- _Filed from the September 2026 audit (branch `lotus`)._
jared added this to the EC fork audit 2026-09 · High milestone 2026-09-12 02:12:57 -04:00
jared added the bugpriority: higharea: denoise labels 2026-09-12 02:12:57 -04:00
jared self-assigned this 2026-09-12 02:12:57 -04:00
jared closed this issue 2026-09-12 11:56:45 -04:00
Author
Owner

Fixed in 936a0835, shipped in 0.25.0-lotus.1 (published by CI from tag v0.25.0-lotus.1) and consumed by cinny at 9a85a487.

Fixed in 936a0835, shipped in `0.25.0-lotus.1` (published by CI from tag v0.25.0-lotus.1) and consumed by cinny at 9a85a487.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
2026-10-14
Dependencies

No dependencies set.

Reference: LotusGuild/element-call#2