WebRTC默认回声消除常失效，因其依赖硬件条件、音频路径纯净性及浏览器策略，非简单开关；需确保设备匹配、禁用系统音频增强、补全约束参数，并优先采用耳机等工程控制手段。
WebRTC 默认回声消除为什么经常失效
WebRTC 的 echoCancellation 是开关型配置，不是“开就一定好”，它依赖设备麦克风与扬声器的物理距离、音频通路延迟、采样率一致性等底层条件。浏览器（尤其 Chrome）在检测到非标准音频路径（比如经过 MediaStreamAudioDestinationNode 二次处理）、或系统音频被第三方软件劫持时，会自动降级或禁用 AEC 模块。
- 常见错误现象：
echoCancellation: true设置后仍有明显回声，且getStats()中查不到audioOutputLevel或echoReturnLoss相关指标 - 必须确保：麦克风和扬声器使用同一设备（如笔记本内置），且未启用“立体声混音”“虚拟音频线”等中间层
- Chrome 115+ 对 USB 外置耳麦的 AEC 支持更稳定，但对 HDMI 音频输出 + 笔记本麦克风组合默认关闭 AEC（因延迟不可控）
- 不要在
constraints里只写{ echoCancellation: true }，务必补全noiseSuppression和autoGainControl，否则部分版本会忽略 AEC：
const constraints = {
audio: {
echoCancellation: true,
noiseSuppression: true,
autoGainControl: false // 推荐设为 false，AGC 与 AEC 冲突高
}
};
手动接入 Web Audio API 做回声抑制的风险点
有人想绕过 WebRTC 内建 AEC，用 ConvolverNode 或 ScriptProcessorNode（已废弃）自实现——这几乎必然失败。Web Audio 的输入流是远端音频解码后的 PCM，而回声消除需要原始麦克风信号（近端）与未经渲染的远端播放信号（参考信号）做实时对齐，Web Audio 无法拿到未混合的原始播放流。
- 典型错误：监听
audio.srcObject的onplay后把audio接入AudioContext→ 实际拿到的是混音后信号，相位/延迟已失真 - WebRTC 的参考信号（rendered audio）不暴露给 JS，仅用于内部 AEC 模块；试图用
MediaRecorder录制audio元素再喂给 Web Audio，引入 ≥200ms 延迟，AEC 完全失效 - 真正可用的替代方案只有 WASM 库（如 RNNoise + SpeexDSP），但需自行管理音频帧同步、延迟补偿、双讲检测（DTX），复杂度远超业务需求
Chrome flags 和 MediaDevices.getSupportedConstraints 的实际意义
chrome://flags/#enable-webrtc-echo-cancellation 这类开关只影响底层模块是否加载，不改变 JS 层行为；而 MediaDevices.getSupportedConstraints() 返回的 echoCancellation 为 true，只代表浏览器声明支持该约束，并不代表当前设备/驱动能跑通。
- 验证是否真生效：调用
navigator.mediaDevices.getUserMedia(constraints)后，检查返回的MediaStreamTrack.getSettings()，确认echoCancellation字段值为true（而非undefined或false） - Android Chrome 不支持
echoCancellation硬件级 AEC（仅靠软件算法），实测回声残留比桌面版高 3–5dB - macOS Safari 17+ 开始支持 AEC，但要求 macOS 13.5+ 且必须使用 FaceTime HD 摄像头配套麦克风，外接 USB 麦克风仍无效果
真正能提升回声控制效果的实操动作
与其折腾参数或替换方案，不如聚焦可落地的工程控制点。回声问题 80% 出在链路设计，而非算法本身。
立即学习“前端免费学习笔记（深入）”；
- 强制使用耳机：这是最有效、零成本的方案。只要用户不外放，
echoCancellation就有足够干净的参考信号 - 避免音频重定向：禁用系统级“听筒”“声音增强”“空间音效”等选项，这些会在驱动层插入额外 DSP，破坏 WebRTC AEC 的参考信号一致性
- 延迟敏感场景（如 KTV 类应用）：改用
RTCAudioSource+ 自定义采集，绕过getUserMedia的默认音频图，但需自己处理采样率转换（必须统一为 48kHz）和静音检测 - 服务端协同：若用 SFU 架构，可在服务器端开启 AEC（如 mediasoup 的
audioLevelObserver+ 自定义处理），但需客户端发送未压缩的原始 Opus 帧（opusDtx: false）
回声消除不是开关游戏，它是硬件能力、驱动状态、浏览器版本、网络抖动共同作用的结果。一个没被注意到的点：Chrome 会根据 RTCPeerConnection 的 iceTransportPolicy 影响音频路径选择——设为 relay 时，部分机器的 AEC 性能反而下降，因为 NAT 打洞改变了音频处理链路。
