获课：xingkeit.top/6667/

AGC 自动增益源码研读：WebRTC 音量自适应调节的底层逻辑

在实时音视频通话中，你说话声音忽大忽小、麦克风忽远忽近，对端听起来却始终稳定如一——这背后的功臣，就是 WebRTC 的自动增益控制（AGC）。它不是简单的"音量旋钮"，而是一套精密的信号处理引擎，横跨预处理、分析、应用三大阶段，用数学和策略把人声"钉"在目标响度上。

整体架构：三阶段流水线

WebRTC 的 AGC 源码集中在 agc_legacy_c 工程下，核心文件为 analog_agc.c、digital_agc.c 和 vad.c。整个处理流程分为三个阶段：

预处理阶段，AGC 首先聚合多通道的增益状态，检测当前帧是否发生削波（clipping）。一旦发现信号峰值触及上限，立即通过 HandleClipping 降低模拟增益等级——每一级对应约 15 个量化单位，范围 0 到 255。这一步的本质是"先保命，再调音"，防止后续增益计算在已经失真的信号上越调越歪。

分析阶段，是整个 AGC 的大脑。VAD 模块先对音频帧做分块 RMS 能量计算，同时输出语音概率。这些数据喂给 LoudnessHistogram，维护一个长期响度直方图——它记录的不是瞬时音量，而是"这个人平时说话有多响"。然后 AGC 对比当前 RMS 与目标电平的差值，决定增益由数字部分还是模拟部分承担：快速变化靠数字增益（响应 100-400 毫秒），慢速漂移靠模拟增益。

应用阶段，分析阶段输出的增益系数最终通过 ApplyDigitalGain 作用于每一个采样点，乘以增益后再截断到 16 位有符号整数的合法范围。整个过程在 10 毫秒帧级别上循环执行，实时性由滑动窗口和重叠保留法保障。

核心策略：不是"放大"，是"拉分布"

很多人误解 AGC 的目标是"让声音变大"。WebRTC AGC1 的设计哲学恰恰相反——把语音的响度统计分布拉向目标响度分布。

具体通过四条策略实现：最大增益策略控制上限，防止爆音；削波策略在预处理阶段就拦截失真；响度直方图策略基于 VAD 能量和语音概率计算当前响度，与目标值对比得到误差；增益划分策略将误差分解为数字增益和模拟增益两部分，数字部分负责快速补偿，模拟部分负责慢速 residual 修正。

数字增益的计算并非线性。AGC 维护了一张增益查找表（CalculateGainTable），根据当前能量区间直接查表得到增益值，避免实时对数运算的开销。同时引入压缩器（UpdateCompressor）对数字增益做平滑处理，防止增益在帧间剧烈跳动——这就是为什么你在通话中感觉音量变化很"柔"，而不是一顿一顿的。

三种模式与关键参数

WebRTC AGC 提供三种运行模式：固定数字增益、自适应模拟增益、自适应数字增益。移动端首选自适应数字增益，响应速度 100-400 毫秒，足够应对用户行走时 ±12dB 的音量波动。

调参的黄金组合经过大量实测验证：单人通话目标电平设 -12dBFS，最大增益 15dB，攻击时间 10 毫秒，释放时间 500 毫秒。攻击时间过短会引入"泵浦效应"——声音像被人一把一把地捏；过长则削波抑制不及时。释放时间控制增益回落速度，太短导致语音间断时增益骤降、噪声突兀，太长则背景噪声被持续放大。

与 3A 模块的协同

AGC 不是孤立运行的。在 WebRTC 音频处理流水线中，推荐顺序是 AEC → ANS → AGC → VAD。当信噪比低于 15dB 时，纯 VAD 准确率跌到 60% 以下，引入谐波检测后可提升至 76%。先做噪声抑制再做增益控制，能避免 AGC 把噪声一起放大——这个顺序的调换，在低信噪比场景下可提升 2-3dB 的语音质量评分。

AGC 的本质，是用算法替用户完成了一件他永远做不好的事：在动态变化的物理世界里，保持声音的恒定与体面。