前面一篇讲的是视频 JitterBuffer。视频卡一下，用户可能还能忍；音频一断，体验会立刻崩掉。实时通话里，声音是第一优先级：画面糊一点还能聊，声音断断续续就像对方在电梯里打电话，听三秒猜五秒，最后只能靠脑补沟通。
WebRTC 的音频接收端不是简单地“收到包就播放”。网络会带来抖动、乱序、丢包和延迟变化，音频播放设备却要求稳定地每 10ms 拉一段 PCM 数据。NetEQ 就是夹在网络和扬声器之间的音频抗抖动核心模块：它缓存 RTP 音频包，估计网络抖动，选择正常播放、加速、减速、扩展、PLC 等策略，尽量让扬声器连续输出声音，同时又不让延迟无限增加。
1. NetEQ的核心问题：网络是抽风的，声卡是守时的
音频播放有一个非常硬的约束：播放设备会按固定节奏要数据。比如 48kHz、10ms 一次回调，每次就需要 480 个采样点。声卡不会因为网络包迟到而体谅你，它就像严格的食堂阿姨，到点就问：“饭呢？”
网络侧却完全不守时。发送端可能每 20ms 发一个 Opus 包，但接收端可能看到这样的到达时间：
包1: 0ms
包2: 23ms
包3: 38ms
包4: 75ms
包5: 81ms
如果直接播放，包4迟到会导致中间没声音；包5又太快到达，队列突然变长。NetEQ 要做的就是把这些不稳定的输入变成相对稳定的输出。
