Fox 2026-06-05: "still two feeds one early (one on time) the early
one must be the mesh for the speakers arriving to the listener" /
"fxhp-android-firefox is also hearing two, one perfectly synced,
other is not."
It was NOT mesh (listeners have no mesh PCs — telemetry confirmed
mesh=0). It was the <audio>-element fallback racing the worklet:
Sequence per peer-joined cycle:
1. flushSfuStreams handed a stale cached stream (no live audio
tracks after the publisher's prior session evicted) to
attachSfuTrack.
2. attachListenerStreamViaAudioContext rejected it via the new
"no live audio tracks" guard.
3. attachSfuTrack FELL THROUGH to the <audio>-element fallback,
created an <audio>, set srcObject = stale stream, called
play(), and stored it in remoteAudio[uuid].
4. Later, live ontrack delivered the real audio stream.
attachListenerStreamViaAudioContext succeeded, the worklet
started, and attachSfuTrack returned early.
5. The <audio> element from step 3 was NEVER torn down. The SFU's
still-alive stale transceiver kept forwarding RTP into it.
6. Listener heard the same publisher twice — <audio> at ~0.5s
native jbuf ("early"), worklet at 4s ("on time").
Fix: when the worklet/AudioContext path succeeds, look up the
stale <audio> element in remoteAudio[uuid] and tear it down
(srcObject=null, pause, remove, delete from map). Single playback
path per uuid going forward. Applies to both listener and
speaker/cohost/host branches.
Russell Ballestrini
61b21a68e2