21、音频拥塞控制：音频编码器码率控制、Opus与拥塞控制、音频优先策略、与视频的带宽竞争
音频拥塞控制，说实话，在WebRTC里是个容易被低估的模块。很多人一提到拥塞控制，脑子里全是视频那一套——GCC、丢包率、码率探测。但音频这边呢？其实更棘手。为什么？因为音频对延迟的敏感度比视频高得多，而且音频的码率本身就低，你再怎么压也压不出多少空间。
我做过一个项目，视频通话里音频突然断断续续，用户投诉说“听不清”。我查了半天，发现是视频把带宽全抢走了，音频被挤得只剩几kbps。嗯，从那以后，我对音频拥塞控制的态度就变了——它不是配角，它是整个通话体验的底线。
音频编码器码率控制：不是你想压就能压
音频编码器的码率控制，说白了就是让编码器根据当前网络状况，动态调整输出码率。但音频编码器不像视频编码器那样灵活。视频你可以从10Mbps降到100kbps，画质虽然烂，但还能看。音频呢？你从64kbps降到8kbps，那声音就完全没法听了。
WebRTC里常用的音频编码器是Opus。Opus支持从6kbps到510kbps的码率范围，但实际应用中，我们通常只用到6-128kbps。为什么？因为再高就浪费带宽了，人耳也听不出区别。
码率控制的核心逻辑是这样的：
- 网络好时：用高码率，保证音质。比如音乐场景用128kbps，语音场景用64kbps。
- 网络差时：逐步降码率，但有个底线。比如语音场景最低降到16kbps，再低就切到窄带模式。
- 极端情况：直接丢包或静音，而不是继续降码率。因为降码率带来的失真比丢包更难受。
我在项目中遇到过一个问题：音频码率降得太快，导致用户听到的声音像“机器人”。后来我加了一个平滑策略——码率变化不能超过每秒20%。这样用户感知不到码率在变，体验就好多了。
核心原则：音频码率控制的目标不是“尽可能低”，而是“在可接受音质下的最低码率”。
Opus与拥塞控制：天生一对
Opus这个编码器，说实话，是为WebRTC量身定做的。它支持多种编码模式，而且可以实时切换。拥塞控制算法可以直接告诉Opus：“兄弟，现在带宽紧张，你降一降码率。” Opus就会立刻调整内部参数，比如从CELT模式切到SILK模式，或者降低采样率。
Opus的码率控制接口很简单：
// 设置Opus编码器码率
opus_encoder_ctl(encoder, OPUS_SET_BITRATE(bitrate));
// 获取当前码率
opus_int32 current_bitrate;
opus_encoder_ctl(encoder, OPUS_GET_BITRATE(¤t_bitrate));但这里有个坑：Opus的码率控制不是瞬时的。你调用OPUS_SET_BITRATE后，编码器需要几个帧的时间才能稳定到目标码率。所以拥塞控制算法不能太激进，否则码率会来回震荡。
我记得有一次，拥塞控制算法每100ms就调整一次码率，结果Opus根本来不及响应，码率一直在目标值上下跳动。后来我加了一个“码率锁定”机制——码率变化后，至少保持500ms不变。这样Opus就有足够的时间稳定下来。
避坑指南：我曾经因为码率调整太频繁，导致Opus编码器内部状态混乱，输出音频出现爆音。后来我限制了码率调整频率，问题就解决了。
音频优先策略：凭什么音频要优先？
音频优先策略，说白了就是：当带宽不够时，先保证音频的码率，视频靠边站。为什么？因为视频卡了还能看，音频卡了就没法交流了。你想想看，视频通话里如果画面不动，你还能忍；但如果声音断了，你肯定会挂电话。
WebRTC里实现音频优先的方式很简单：
- 带宽分配：先给音频分配最低保证码率（比如32kbps），剩下的带宽再给视频。
- 丢包保护：音频的FEC（前向纠错）优先级高于视频的FEC。
- 重传策略：音频的NACK（丢包重传）请求优先处理。
但这里有个问题：音频优先不等于音频独占。如果视频完全没带宽，画面就会卡死，用户也会不爽。所以实际策略是“音频保底，视频尽力”。
我做过一个实验：在带宽只有100kbps的情况下，音频固定占32kbps，视频占剩下的68kbps。结果视频虽然模糊，但还能动；音频清晰流畅。用户反馈说“虽然画面不清晰，但至少能正常通话”。嗯，这就是音频优先的价值。
注意：音频优先策略不能滥用。如果音频码率设置过高，视频就会被饿死。建议音频最低码率不要超过64kbps。
与视频的带宽竞争：一场不公平的战争
音频和视频的带宽竞争，说白了就是一场“谁更重要的战争”。音频说：“我更重要，因为我影响沟通。” 视频说：“我也重要，因为用户想看脸。” 结果呢？音频赢了，因为WebRTC的设计者更偏向音频。
但实际场景中，竞争不是非黑即白的。比如在屏幕共享场景下，视频（屏幕内容）可能比音频更重要。所以WebRTC引入了“优先级”机制：
- 音频：默认优先级最高（priority=1）。
- 视频：默认优先级中等（priority=2）。
- 屏幕共享：默认优先级最高（priority=1），和音频同级。
带宽分配算法会按照优先级来分配带宽。优先级高的流先拿到保证码率，优先级低的流拿剩余带宽。
我记得有一次，用户开了屏幕共享，结果音频码率被屏幕共享挤占了。我查了一下，发现屏幕共享的优先级和音频一样，但屏幕共享的码率需求更高（比如1Mbps），导致音频只能拿到最低码率。后来我调整了策略：屏幕共享的优先级虽然高，但它的“保证码率”设得低一些（比如200kbps），这样音频就不会被饿死。
下面这张图展示了音频和视频在带宽竞争中的关系：
从这张图可以看出，音频优先策略的核心就是“先保证音频，再考虑视频”。但实际实现中，还需要考虑动态调整。比如当视频完全卡死时，可以适当降低音频码率，给视频留一点空间。
我建议你在实现带宽竞争逻辑时，注意以下几点：
- 不要硬编码优先级：优先级应该可以根据场景动态调整。比如屏幕共享时，视频优先级可以提升。
- 设置码率上下限：音频和视频都要有最低码率和最高码率，避免一方被完全饿死。
- 监控实际码率：不要只看目标码率，要看编码器实际输出的码率。有时候编码器会“偷懒”，输出码率低于目标值。
个人经验：我在项目中用了一个“带宽预算”机制。先给音频分配保证码率，再给视频分配剩余带宽的80%，剩下的20%作为缓冲。这样即使带宽波动，也不会立刻影响音视频质量。
音频拥塞控制，说白了就是一场“保底”的游戏。你不需要让音频跑得最快，但你要保证它不掉队。Opus给了你灵活的码率控制，音频优先策略给了你带宽分配的底气，而带宽竞争逻辑则决定了最终的体验。嗯，把这些都做好了，你的WebRTC通话就不会差到哪里去。
公众号:蓝海资料掘金营，微信deep3321