3. 时钟与时间基准
时钟，说白了就是整个多媒体系统的「心跳」。
我刚开始做音视频同步时，总觉得时钟这东西很简单——不就是个计时器吗？直到有一次，我在一个直播项目里遇到了音频和视频越跑越偏的问题，查了整整三天，最后发现是三个时钟的参考源不一致。嗯，从那以后，我再也不敢小看时钟模型了。
这一章，我们就来拆解系统时钟、音频时钟、视频时钟这三个核心概念，以及它们之间到底怎么配合。
3.1 系统时钟：整个播放器的「基准时间轴」
系统时钟，也叫参考时钟。它是一条全局的时间轴，所有音视频数据都在这条轴上对齐。
你想想看，音频有自己的采样率，视频有自己的帧率，它们各自独立运行。如果没有一个统一的参考，音频播音频的，视频播视频的，那画面和声音迟早要分家。
系统时钟的核心职责：
- 提供一个单调递增的时间基准
- 所有音视频时间戳都基于这个基准进行换算
- 驱动播放进度、跳转、暂停等控制逻辑
在常见的播放器架构里，系统时钟通常由 AudioTrack 或 MediaClock 来维护。我个人习惯把系统时钟的精度设在微秒级，因为音频的采样周期往往在几十微秒，精度不够的话，同步误差会累积。
3.2 音频时钟：以「采样点」为节拍
音频时钟，本质上是音频硬件驱动出来的时间线。
音频设备有一个固定的采样率，比如 44100 Hz 或 48000 Hz。每采集或播放一个采样点，时钟就往前走一步。音频时钟的推进是连续的、均匀的，因为它由硬件晶振直接驱动。
这里有个关键点：音频时钟是物理时钟。它不受 CPU 负载、线程调度的影响。只要硬件不坏，它就能稳定地往前走。
避坑指南： 我曾经在一个项目中直接用系统时间戳来驱动音频播放，结果发现音频缓冲区经常出现欠载或溢出。后来才意识到，音频时钟必须从音频设备的回调中获取，而不是从系统 gettimeofday 拿。音频硬件有自己的节奏，你得跟着它走。
3.3 视频时钟：以「帧」为节拍
视频时钟，跟音频时钟完全不同。它是以帧为单位的。
每一帧视频都有一个显示时间戳（PTS）。视频时钟的任务就是：在系统时钟到达某个时间点时，把对应的帧显示出来。
但问题来了——视频帧的间隔不是均匀的。比如 30fps 的视频，理论上是每 33.33ms 一帧。但实际编码时，I 帧、P 帧、B 帧的大小差异很大，解码耗时也不同。所以视频时钟的推进是「跳跃式」的，它依赖于帧的到达和解码完成。
| 时钟类型 | 驱动源 | 推进方式 | 精度 | 是否受 CPU 影响 |
|---|---|---|---|---|
| 系统时钟 | 软件计时器 / 音频回调 | 连续 | 微秒级 | 是 |
| 音频时钟 | 音频硬件晶振 | 连续 | 采样点级 | 否 |
| 视频时钟 | 帧解码完成事件 | 跳跃式 | 帧级 | 是 |
3.4 三个时钟的关系：谁主谁从？
在实际系统中，三个时钟不是平起平坐的。它们有主从关系。
最常见的做法是：以音频时钟为主时钟。
为什么？因为人耳对声音的抖动比眼睛对画面的抖动敏感得多。音频一旦出现断续、卡顿，用户立刻就能察觉。视频稍微丢一帧、晚一帧，人眼反而不太敏感。
所以，系统时钟通常会跟随音频时钟。视频时钟则根据系统时钟来调整自己的显示时机。
注意： 如果音频设备出了问题（比如采样率不匹配、驱动异常），音频时钟会变得不可靠。这时候需要切换到视频时钟作为主时钟，或者启用系统时钟的软件回退模式。我在一个嵌入式项目中就遇到过音频驱动在低功耗模式下时钟漂移的问题，最后不得不加了一个时钟监控线程，实时检测三个时钟的偏差。
3.5 时钟同步的核心流程
下面这张图展示了三个时钟在播放器中的协作关系：
3.6 时钟漂移与校正
理想情况下，三个时钟应该完全同步。但现实是，每个时钟都有自己的漂移率。
音频时钟的漂移来自晶振的温漂和老化。视频时钟的漂移来自解码时间的波动。系统时钟的漂移来自软件计时器的不精确。
我常用的校正策略是：
- 周期性校准：每 1 秒计算一次系统时钟与音频时钟的偏差，如果超过阈值（比如 5ms），就微调系统时钟的速率。
- 丢帧/插帧：当视频时钟落后系统时钟太多时，可以丢一帧来追赶；反之则重复显示上一帧。
- 重采样：对于音频，如果时钟偏差在 1% 以内，可以通过音频重采样来微调播放速度，人耳几乎听不出来。
个人经验： 我曾经在一个多房间同步的系统中，发现不同设备的音频时钟漂移方向竟然相反。一台设备偏快，一台设备偏慢。最后我不得不在每个设备上独立做时钟校准，而不是统一用一个参考时钟。所以，时钟模型不是一成不变的，你得根据实际硬件特性来调整。
3.7 小结
系统时钟、音频时钟、视频时钟，这三者构成了音视频同步的基石。音频时钟是物理时钟，最稳定，通常作为主时钟；视频时钟是逻辑时钟，跟随系统时钟；系统时钟则是中间的桥梁，负责协调两者。
理解这三个时钟的概念和关系，你就能看懂后面章节中所有同步策略的底层逻辑了。