Category: Video SDK — Web SDK version: @zoom/videosdk 2.4.5 Browser: Microsoft Edge (Chromium) on Windows Works correctly on: Google Chrome, same OS
Description
On Microsoft Edge, any audio coming out of the participant’s speakers is captured by their microphone and sent to the other participants — including audio from unrelated applications (music, a video in another tab). The same steps in Chrome on the same machine are fine: the audio is cancelled as expected. Our app passes no custom audio constraints, only backgroundNoiseSuppression: true.
Root cause
Reading dist/lib/js_media.min.js, the SDK chooses between two playback routes based on isChromeWideAECEnabled = isSupportChromeWideAEC():
- when true, session audio plays through the page’s
AudioContext(this.audioCtx); - when false, it plays through a media element plus a peer connection (
this.audioDomNode/CloseBoringPeerConnection).
Routing playback through an AudioContext is only echo-cancellable because of Chromium’s Chrome-wide echo cancellation, which is what makes non-WebRTC output visible to the AEC reference signal. Without that feature, the echo canceller never sees what the speakers are playing.
The support check is:
isSupportChromeWideAEC(){
const e = this.isChromeOS() && LZ(116);
return (this.isMac() || this.isWindows() || this.isLinux()) && LZ(111) || e || isGoogleMeetMode
}
and LZ(n) resolves to a("chrome", n), whose helper explicitly accepts Edge alongside Chrome and Opera:
a=(e,t)=>{ ... if("chrome"===e||"chromium"===e){ if(isChrome()||isEdge()||isOpera()) return versionGte(i,t) } ... }
So on Edge/Windows >= 111 the SDK concludes Chrome-wide AEC is available purely from browser name and version, and switches playback to the AudioContext path on that basis.
Chrome-wide echo cancellation is a Chromium feature-flag default, not a guaranteed property of a Chromium version. Edge does not necessarily ship Chrome’s flag defaults. When it is off in Edge, the SDK is on the AudioContext playback path with no working echo cancellation, and all speaker output leaks into the captured microphone stream.
This is a version/UA sniff where a capability check belongs. Note also that the SDK’s own isChrome getter buckets modern Edge as Chrome, so there is no Edge-specific branch anywhere in the audio path.
For completeness, backgroundNoiseSuppression is not involved: isSupportAudioAEC() is disabled only for MSFT Teams Android Room devices and an explicit aec:0 UA override, so the capture constraint remains echoCancellation: true on Edge. The defect is on the playback reference path, not on capture.
Steps to reproduce
- Join a Video SDK session in Microsoft Edge on Windows, microphone on, using laptop speakers (not a headset).
- Play music or a video — another browser tab or a desktop application.
- From a second participant on any browser, listen to the Edge participant: the media is clearly audible.
- Repeat in Chrome on the same machine: the media is cancelled.
Expected
Speaker output should be cancelled from the captured microphone stream on Edge as it is on Chrome.
Request
Please make isSupportChromeWideAEC() feature-detect Chrome-wide echo cancellation rather than infer it from browser name and version, so Edge (and any other Chromium embedder whose flag defaults differ from Chrome’s) falls back to the media-element playback path instead of silently losing echo cancellation.
Is there an interim escape hatch we can use from application code to force the audioDomNode playback path on Edge? customAudioConstraints only affects capture, so it does not appear to address this, and per the docs it would also disable backgroundNoiseSuppression for us.