3. 音视频时钟模型：系统时钟、音频时钟、视频时钟，谁做主时钟？

时钟，是音画同步的命根子。

你想想看，音频有自己固定的采样率，视频有自己固定的帧率，系统还有个全局时间。这三个时钟如果不统一，画面和声音迟早要分家。我刚开始做播放器的时候，就天真地以为只要把音频和视频分别按自己的节奏送出去就行了。结果呢？播了不到两分钟，口型就对不上了。

这一章，我们就来拆解这三个时钟，看看它们各自是什么角色，以及——到底谁说了算。

3.1 三种时钟，各司其职

先给个直观的定义：

时钟类型	驱动源	典型增量	特点
系统时钟	CPU 晶振 / 操作系统时间	毫秒级（1ms）	绝对时间，单调递增，不受媒体流影响
音频时钟	音频设备采样率（如 44100 Hz）	采样周期（约 22.7 µs）	硬件驱动，精度极高，抖动极小
视频时钟	显示设备刷新率 / 帧率	帧周期（如 33.3 ms @ 30fps）	受渲染和合成影响，抖动较大

说白了，系统时钟是「墙上的钟」，音频时钟是「节拍器」，视频时钟是「翻页器」。它们各自独立运行，但必须协同工作。

3.2 谁做主时钟？三种主流策略

这个问题没有标准答案。不同的场景，选不同的主时钟。我这些年做过的项目里，基本就这三种玩法：

策略一：音频为主时钟（Audio Master）

这是最常用的方案。为什么？因为人耳对声音的抖动比眼睛对画面的抖动敏感得多。音频一旦卡顿、断续、变调，观众立刻就能察觉。画面稍微丢一帧，反而没那么明显。

具体做法：

• 音频时钟作为参考时间轴
• 视频帧根据音频时钟的进度来调整显示时间
• 如果视频落后了，就加速渲染或丢帧；如果超前了，就等待

我在项目中遇到过一个问题：某些低端 Android 设备上，音频时钟的驱动回调不稳定，偶尔会跳变。这时候如果视频完全跟着音频走，画面就会突然抽搐一下。后来我加了一个「时钟平滑滤波器」，对音频时钟的增量做限幅处理，才把这个问题压下去。

策略二：视频为主时钟（Video Master）

这种方案比较少见，但也不是没有。比如在视频编辑软件里，用户拖动时间轴预览时，画面的实时响应比声音的连续性更重要。这时候如果音频卡一下，用户能接受；但画面如果卡住不动，操作体验就很糟糕。

适用场景：

• 视频剪辑预览
• 游戏录像回放
• 低延迟直播（画面优先）

不过说实话，我很少用这个方案做正式播放器。因为一旦视频时钟抖动，音频就得跟着变速，听起来会变调。除非你用了变速不变调的算法（比如 WSOLA 或相位声码器），否则音质会很难听。

策略三：外部时钟（External Master）

系统时钟作为主时钟，音频和视频都去对齐它。这个方案在「音画同步要求极高」的场景下很常见，比如：

• 多设备同步播放（如拼接屏、分布式影院）
• 音视频录制（采集端需要统一时间戳）
• 专业广电系统（如 SMPTE 时间码）

我记得有一次做多屏互动项目，三台电视同时播放同一段内容，要求误差不超过 10 毫秒。音频主时钟和视频主时钟都不行，因为每台设备的音频硬件时钟有微小偏差。最后只能用 NTP 同步系统时钟，再让所有播放器以系统时钟为基准来调度。

3.3 时钟模型的核心：时间戳映射

不管选谁做主时钟，最终都要解决一个问题：把音频和视频的时间戳，映射到主时钟的时间轴上。

举个例子，假设音频主时钟的当前值是 t_audio，视频帧的 PTS 是 t_video。我们需要计算：

diff = t_video - t_audio

if diff > 阈值:
    // 视频落后了，加速或丢帧
    drop_frame() 或 speed_up()
else if diff < -阈值:
    // 视频超前了，等待或重复显示
    wait() 或 repeat_frame()
else:
    // 正常显示
    render_frame()

这个阈值怎么定？我个人习惯设 40 毫秒。小于 40ms 的偏差，人眼基本感觉不到。超过 40ms，口型就开始对不上了。

3.4 时钟漂移：最隐蔽的敌人

你以为选好了主时钟就万事大吉了？太天真了。

时钟漂移（Clock Drift）才是真正的坑。音频设备的晶振和视频设备的晶振，频率不可能完全一致。哪怕差个 0.01%，播了十分钟就能差出几十毫秒。

我曾经在一个项目里遇到过：播放器跑了一个小时后，声音比画面快了将近 200 毫秒。查了半天，发现是音频设备的采样率标称 44100 Hz，实际是 44105 Hz。音频时钟比真实时间跑得快了一点点。

解决方案有两种：

1. 重采样（Resampling）：动态调整音频的采样率，让音频时钟和主时钟保持一致。这是最优雅的做法，但需要实时重采样器，计算量稍大。
2. 丢帧/插帧（Frame Dropping/Insertion）：定期检查时钟偏差，如果音频快了，就悄悄丢掉一帧音频；如果慢了，就重复一帧。这种做法简单粗暴，但偶尔会有可感知的「咔哒」声。

3.5 时钟模型架构图

下面这张图，是我自己画的一个典型音视频时钟模型。它展示了三种时钟的关系，以及主时钟如何驱动整个播放流程。

3.6 实战建议：如何选择主时钟

说了这么多，到底怎么选？我根据自己的经验，给一个简单的决策流程：

• 普通播放器（本地文件、流媒体） → 音频主时钟。这是最稳的，用户感知最好。
• 视频编辑/预览 → 视频主时钟。操作响应优先，音频可以变速。
• 多设备同步/录制 → 外部系统时钟。所有设备统一时间基准。
• 低延迟直播（如在线会议） → 音频主时钟 + 动态重采样。既要低延迟，又要音质。