1. WebRTC 音频同步概述
音频同步，说白了就是让声音和画面「对上嘴」。你想想看，视频会议里如果嘴巴动了半天声音才传过来，或者声音提前到了，那体验有多糟糕。我做了这么多年实时通信，可以负责任地告诉你——同步问题往往是用户投诉的第一大原因。
这一章我们先打好基础。搞清楚音频同步到底难在哪，RTP 时间戳和 NTP 时间是什么关系，以及音视频同步到底该以谁为基准。
音频同步的挑战：为什么这么难？
很多人以为同步就是把时间戳对齐就行了。嗯，要是这么简单就好了。实际项目中我踩过的坑，随便列几个你就明白了：
- 网络抖动：数据包到达时间不均匀，有的早到有的晚到。你没法保证接收端看到的就是发送端发出的节奏。
- 时钟漂移：发送端和接收端的时钟不是同一个晶振。哪怕都是 48kHz 采样率，实际跑起来也会有细微偏差。我遇到过两台设备跑了半小时，音频比视频快了 200ms 的情况。
- 不同采集路径：麦克风采集音频、摄像头采集视频，这两个硬件启动时间不同，驱动延迟也不同。你拿到的两个时间戳，基准点可能差了十几毫秒。
- 处理延迟不对称：音频编解码通常比视频快得多。音频可能 10ms 就处理完了，视频要 30-50ms。这就导致即使网络没问题，两端播放时刻也不一致。
核心矛盾：音频要求连续、低延迟；视频要求帧率稳定、画面完整。两者对网络丢包和抖动的容忍度完全不同。同步的本质，是在两条不同特性的数据流之间建立统一的播放时间轴。
RTP 时间戳与 NTP 时间的关系
WebRTC 里用两套时间系统。搞懂它们的关系，是理解同步的第一步。
RTP 时间戳：这是采样时钟的计数器。音频的 RTP 时间戳以采样率为单位递增。比如 48kHz 采样率，每采集一个样本，时间戳加 1。它只反映采样时刻的相对顺序，不表示绝对时间。
NTP 时间：这是网络时间协议的时间，表示绝对时刻。WebRTC 的音频引擎会在 RTP 包中携带 NTP 时间信息，告诉接收端「这个包是在什么绝对时间被发送的」。
两者的关系可以用一个公式表达：
播放时刻 = NTP_base + (RTP_timestamp - RTP_base) / 采样率其中 NTP_base 和 RTP_base 是某个参考点的对应值。接收端拿到这个映射关系，就能把 RTP 时间戳换算成统一的 NTP 时间轴。
| 属性 | RTP 时间戳 | NTP 时间 |
|---|---|---|
| 含义 | 采样时刻的相对计数 | 绝对时间（秒） |
| 单位 | 采样周期（如 1/48000 秒） | 秒（高精度小数） |
| 是否单调递增 | 是（采样率固定时） | 是 |
| 是否受网络影响 | 否（发送端生成） | 否（发送端生成） |
| 用于同步 | 音频内部连续性 | 音视频跨流对齐 |
我的经验：调试同步问题时，我习惯先看 NTP 时间是否准确。如果发送端的 NTP 时钟本身就不准，后面所有同步算法都是白搭。曾经有个项目，服务器 NTP 同步周期设成了 1 小时，结果时钟漂移导致音视频每 20 分钟就错位一次。后来改成 5 分钟同步一次，问题就解决了。
音视频同步的基准选择
同步总得有个参考系。是以音频为基准调整视频，还是以视频为基准调整音频？或者两者都往一个虚拟时钟上靠？
WebRTC 的默认策略是：以音频为同步基准。为什么？
- 人耳对音频抖动的敏感度远高于人眼。音频如果出现断续、卡顿，用户立刻能察觉。视频稍微丢一帧，人眼可能根本注意不到。
- 音频的播放节奏是连续的。你没法让音频「等一等」视频，因为音频一旦暂停，听感就断了。视频可以适当丢帧或重复帧，用户感知不强。
- 音频的 RTP 时间戳更密集（每样本一个），时间分辨率更高。用它做基准，同步精度可以做到亚毫秒级。
具体做法是：接收端维护一个音频播放时钟，视频渲染引擎根据这个时钟来调整自己的播放时刻。如果视频帧到早了，就等一等；到晚了，就跳过或重复一帧。
注意：以音频为基准不是万能的。如果音频流本身不稳定（比如丢包严重、抖动过大），视频跟着音频跑反而会加剧不同步。我在一个弱网项目中就遇到过这种情况——音频因为丢包恢复导致播放速度忽快忽慢，视频跟着调整，结果画面像在「抽搐」。后来我们加了一个平滑滤波器，让视频的调整速度慢于音频的变化速度，才稳住体验。
还有一种方案是以 NTP 为公共基准。音频和视频各自维护一个播放时钟，都向 NTP 时间对齐。这种方案的优点是两条流独立，互不影响。缺点是两端都需要精确的 NTP 同步，否则各自对齐的基准不同，反而对不齐。
下面这张图展示了 WebRTC 音频同步的核心逻辑：
从这张图可以看得很清楚：音频采集时生成 RTP 时间戳，同时记录 NTP 时间。经过网络传输后，接收端先做抖动缓冲，再把 RTP 时间戳换算成 NTP 时间，建立统一的播放时钟。视频渲染引擎就跟着这个时钟走。
避坑指南：我曾经在实现同步时犯过一个低级错误——直接把 RTP 时间戳当绝对时间用。结果音频和视频的采样率不同（音频 48kHz，视频 90kHz），两个时间戳的增量速度不一样，同步完全对不上。记住，RTP 时间戳只在同一种媒体流内部有意义，跨流比较必须用 NTP 时间。
总结一下这一章的核心：音频同步的挑战来自网络、时钟、硬件、处理延迟多个方面。RTP 时间戳负责音频内部的连续性，NTP 时间负责跨流的绝对对齐。WebRTC 默认以音频为同步基准，因为人耳对音频抖动的容忍度最低。理解这些基础，后面讲具体算法和实现时你才能知道每一步在解决什么问题。