1. WebRTC 音频同步问题全解：课程导学与同步基础概念
大家好，我是你们这门课的主讲。做了这么多年音视频，我最大的感触就是：音频同步这玩意儿，看着简单，坑是真多。
你想想看，两个人视频通话，画面卡了还能忍，声音对不上嘴型，那体验直接归零。我早期做的一个项目，就是因为唇音不同步，被客户在线上会议里当场怼回来。嗯，从那以后，我就把同步问题当成了头等大事。
这门课一共30章，咱们今天先打个底。把“同步”到底是个什么东西，为什么它这么难搞，以及我们后续会用到哪些武器，先捋清楚。
1.1 什么是音频同步？
说白了，音频同步就是让声音和画面在时间上“对齐”。
在WebRTC的世界里，同步分两个层面：
- 唇音同步（Lip Sync）：音频和视频的同步。这是用户感知最明显的。
- 多流同步：比如你同时开着麦克风和共享屏幕，两个音频流之间不能有延迟。
我个人的习惯是，把同步的容忍度控制在 ±40ms 以内。超过这个范围，人眼就能察觉到不对了。
核心指标： WebRTC 官方建议的音频同步误差目标是 < 100ms。但实际项目中，我建议你按 40ms 去卡，给自己留点余量。
1.2 为什么同步这么难？
你可能会问：“不就是把时间戳对上吗？”
哪有那么简单。音频和视频是两个完全不同的“物种”。
| 维度 | 音频 | 视频 |
|---|---|---|
| 采样率 | 固定（如 48kHz） | 可变（如 30fps） |
| 数据量 | 小，连续 | 大，离散帧 |
| 处理耗时 | 低（几毫秒） | 高（几十毫秒） |
| 网络抖动 | 用Jitter Buffer吸收 | 用帧缓存吸收 |
你看，音频是“流”，视频是“帧”。它们从采集、编码、网络传输到解码播放，每一步的延迟都不一样。我在项目中遇到过最典型的情况：视频解码器卡了一下，音频还在正常播放，结果画面就比声音慢了半拍。
避坑指南： 我曾经以为只要两端都用 NTP 对时就能解决一切。结果发现，采集时间戳和播放时间戳之间的漂移，才是真正的元凶。别迷信绝对时间。
1.3 同步的核心机制：RTP 时间戳与 RTCP SR
WebRTC 同步的基石，是两个东西：RTP 时间戳和 RTCP 发送端报告（SR）。
1.3.1 RTP 时间戳
每个音频包和视频包，都带了一个 RTP 时间戳。但这个时间戳是“相对”的，它只表示这个包在流内部的时序位置。音频和视频的 RTP 时间戳，用的是不同的时钟频率，没法直接比。
// 音频 RTP 时间戳示例（48kHz 采样率）
// 第 1 个包：timestamp = 0
// 第 2 个包：timestamp = 480 （10ms 的音频数据）
// 第 3 个包：timestamp = 960
1.3.2 RTCP SR 报告
这才是同步的关键。发送端会定期发 RTCP SR 包，里面包含了一个“映射关系”：
- NTP 时间戳：绝对时间（wall clock）。
- RTP 时间戳：对应那个时刻的流内时间。
接收端拿到这个映射，就能把音频和视频的 RTP 时间戳，都换算到同一个 NTP 时间轴上，然后对齐播放。
我的经验： 调试同步问题时，第一步就是抓包看 RTCP SR。如果 SR 里的 NTP 和 RTP 映射关系是乱的，那后面所有努力都是白费。
1.4 本章知识体系总览
为了让你对后续内容有个整体印象，我画了张图。这张图基本就是咱们这门课要攻克的所有关卡。
1.5 你需要准备什么？
这门课不是纯理论。我会带着你动手。所以，请提前准备好这些：
- 浏览器：Chrome 或 Edge 最新版，打开
chrome://webrtc-internals。 - 抓包工具：Wireshark，用来分析 RTP/RTCP 包。
- 代码环境：Node.js 16+，以及一个简单的 Web 服务器。
- 耐心：同步问题有时候很玄学，需要反复验证。
一个小建议： 我习惯在本地搭一个简单的 PeerConnection，然后用 getStats() API 实时观察 currentRoundTripTime 和 jitter 指标。这比看日志直观多了。
好了，第一课就到这里。同步的基础概念，说白了就是“对齐时间轴”。后面的章节，我们会深入到每一行代码、每一个参数里去。准备好了吗？