16、音频处理：Opus编码器配置、回声消除(AEC)、噪声抑制(ANS)、自动增益控制(AGC)

音频处理这块，说实话是WebRTC里最容易被忽视但又最影响体验的环节。你想想看，视频卡顿一下还能忍，音频要是炸了、有回声、或者声音忽大忽小，用户直接就挂电话了。我早期做项目时就吃过这个亏，后来才老老实实把Opus、AEC、ANS、AGC这几个东西摸透。

今天咱们就把这四件套掰开揉碎了讲。嗯，先从编码器说起。

16.1 Opus编码器：为什么WebRTC选它？

Opus是目前WebRTC默认的音频编码器，也是我个人最推崇的。它是个混合编码器，同时支持SILK（语音）和CELT（音乐）两种模式。说白了，它能根据你说话还是唱歌自动切换编码策略。

我在项目中遇到过一个问题：默认Opus配置在弱网环境下语音质量下降明显。后来发现是没调对比特率和复杂度。下面是我常用的配置模板：

// 创建 Opus 编码器实例
const opusEncoder = new RTCRtpSender.createEncodedStreams({
  codec: 'opus/48000',
  // 关键参数配置
  parameters: {
    // 比特率：16kbps 适合语音，32kbps 适合音乐
    'maxaveragebitrate': 32000,
    // 复杂度：0-10，越高越耗CPU
    'complexity': 8,
    // 帧长：20ms 是延迟和质量的平衡点
    'ptime': 20,
    // 启用DTX（不讲话时降低码率）
    'usedtx': 1,
    // 启用FEC（前向纠错）
    'useinbandfec': 1
  }
});

16.2 回声消除（AEC）：最让人头疼的模块

回声消除，说白了就是让扬声器出来的声音不要被麦克风再收回去。你想想看，如果两个人开免提通话，AEC没做好，那就是无限循环的啸叫。

WebRTC的AEC是基于自适应滤波器的，它通过分析扬声器输出的参考信号和麦克风采集的信号，动态计算出回声路径的冲击响应，然后反向抵消。嗯，原理听起来简单，实际调起来坑很多。

配置AEC的关键参数：

// 在 PeerConnection 中启用 AEC
const constraints = {
  audio: {
    echoCancellation: true,
    // 以下参数可选，但建议显式设置
    echoCancellationType: 'system', // 或 'browser'
    // 延迟自适应范围（毫秒）
    latencyHint: 'interactive'
  }
};

// 更精细的控制（通过底层API）
const audioContext = new AudioContext();
const source = audioContext.createMediaStreamSource(stream);
const aecNode = audioContext.createWebRTCAEC({
  // 滤波器长度：一般设为 256ms 的采样点数
  filterLength: 2048,
  // 收敛速度：0.1-0.9，越大越快但可能不稳定
  adaptationRate: 0.7
});

16.3 噪声抑制（ANS）：让背景安静下来

噪声抑制，说白了就是把环境噪音去掉。WebRTC的ANS用的是谱减法，它先估计噪声的频谱特征，然后从带噪语音中减去这部分能量。

我刚开始做的时候觉得这玩意儿很简单，不就是个滤波器嘛。后来发现，噪声类型千变万化——风扇的平稳噪声、键盘的突发噪声、马路的非平稳噪声，处理方式完全不同。

// 启用噪声抑制
const constraints = {
  audio: {
    noiseSuppression: true,
    // 抑制强度：0-1，默认0.5
    noiseSuppressionLevel: 0.7
  }
};

// 自定义噪声抑制参数（通过底层处理链）
const noiseReducer = new NoiseSuppression({
  // 噪声估计更新速度
  noiseUpdateSpeed: 0.1,
  // 抑制深度（dB）
  suppressionDepth: 15,
  // 保留语音的阈值
  voicePreservationThreshold: 0.3
});

16.4 自动增益控制（AGC）：音量别忽大忽小

AGC的作用是让麦克风采集的音量保持在一个合适的范围内。你想想看，用户离麦克风远的时候声音小，近的时候声音大，没有AGC的话对方就得不停调音量。

WebRTC的AGC有两种模式：线性模式和自适应模式。线性模式简单粗暴，直接放大信号；自适应模式会动态调整增益，避免过载。

// 启用自动增益控制
const constraints = {
  audio: {
    autoGainControl: true,
    // 目标音量（dBFS，0为最大）
    targetLevel: -3,
    // 最大增益（dB）
    maxGain: 20,
    // 压缩比：1:1 到 20:1
    compressionRatio: 4
  }
};

// 更精细的AGC配置
const agcConfig = {
  // 启用自适应模式
  mode: 'adaptive',
  // 目标峰值电平（dBFS）
  targetPeakLevel: -2.0,
  // 增益变化速度（dB/s）
  gainChangeSpeed: 3,
  // 噪声门限：低于此电平不放大
  noiseGateThreshold: -50
};

16.5 四件套的协同工作

这四个模块不是独立工作的，它们有严格的顺序。下面这张图展示了WebRTC音频处理链的典型流程：

这个顺序是固定的。为什么？因为如果先做AGC，把噪声和回声都放大了，后面的AEC和ANS压力会非常大。我见过有人把AGC放在AEC前面，结果回声反而更严重了。

16.6 实战配置建议

根据不同场景，我总结了三种配置模板：

场景	Opus比特率	AEC	ANS	AGC
语音通话（低带宽）	16 kbps	开启，强度高	开启，强度中	开启，目标-3dB
视频会议（普通）	32 kbps	开启，强度中	开启，强度中	开启，目标-2dB
音乐直播（高质量）	64-128 kbps	关闭或低强度	关闭或低强度	关闭

---