2、音同步核心指标：延迟、抖动、漂移与时间戳机制

做音同步，说白了就是跟四个数字打交道：延迟、抖动、漂移，还有时间戳。这四兄弟搞不定，你的音频视频就永远对不上。我最早做直播项目时，就吃过它们的亏——画面和声音差了半秒，用户全跑了。

今天咱们把这四个指标彻底讲透。你理解了它们，音同步的底层逻辑就通了八成。

延迟就是数据从源头到耳朵的时间差。单位是毫秒（ms）。

你想想看，一个音频帧从采集、编码、网络传输、解码，再到播放，每一步都在贡献延迟。

关键认知：延迟不是越低越好。太低的延迟意味着缓冲不足，网络一抖就卡顿。我个人习惯在直播场景控制在 200-400 ms，实时通话则压到 100 ms 以内。

我曾经在一个远程演奏项目中，把端到端延迟压到了 30 ms。代价是什么？播放缓冲几乎为零，网络稍微波动就爆音。后来我妥协到 80 ms，体验反而好了。

抖动是延迟的变化量。网络不是稳定的水管，它有时快有时慢。抖动就是这种快慢的差值。

举个例子：

这 100 ms 的波动就是抖动。你想想看，播放器如果按固定节奏播放，遇到晚到的包就只能等——这就产生了卡顿。

我的经验：抖动比延迟更致命。延迟高但稳定，用户能适应；抖动大，用户直接摔耳机。所以抗抖动缓冲（Jitter Buffer）是每个音频引擎的核心组件。

抖动的计算方式很简单：

Jitter = |Delay(n) - Delay(n-1)|

实际工程中常用滑动窗口的平均抖动值：

Jitter_avg = (Jitter_avg * 0.875) + (Jitter_current * 0.125)

这个 0.875 和 0.125 是经验值，WebRTC 里就是这么算的。我建议你直接抄。

漂移是时钟频率的微小偏差。没有两个晶振是完全一样的。发送端和接收端的时钟，一天下来可能差出几秒。

为什么会这样？

每小时就差了 3.6 个样本。半小时后，音频和视频的同步关系就崩了。

注意：漂移是累积的。延迟和抖动是瞬时问题，漂移是长期问题。很多新手只处理抖动，忽略了漂移，结果跑 10 分钟后音画不同步。

我做过一个 24 小时不间断的音频流项目。前 10 分钟一切正常，第 2 小时开始出现可感知的不同步。查了三天，最后发现是接收端的时钟比发送端慢了 0.02%。解决方案是引入时钟同步协议（NTP/PTP）和自适应重采样。

时间戳是每个音频帧的“出生证明”。它告诉播放器：这个帧应该在什么时候被播放。

在 RTP 协议里，音频时间戳的单位是采样周期。比如 48000 Hz 采样率，每个时间戳单位就是 1/48000 秒 ≈ 20.8 微秒。

// RTP 音频时间戳示例
// 采样率: 48000 Hz
// 帧长: 20 ms (960 个样本)
// 第一个帧的时间戳: 0
// 第二个帧的时间戳: 960
// 第三个帧的时间戳: 1920

时间戳的核心作用有三个：

核心原则：时间戳必须单调递增，不能回退。一旦回退，播放器会认为发生了乱序或重传，导致同步逻辑混乱。

下面这张图展示了四个指标在音同步系统中的位置和关系：

这四个指标不是独立的。你调一个，其他三个跟着变。

我的建议：先保证时间戳正确，再处理抖动，最后优化延迟。漂移是长期问题，上线前就要做好时钟同步方案。别反过来——先压延迟，结果抖动和漂移全炸了。

嗯，这四个指标讲完了。你记住一句话：时间戳是骨架，延迟是血肉，抖动是病痛，漂移是慢性毒药。理解了它们，你就能看懂后面所有同步策略的设计意图。