10、音频时钟与同步：音频时钟源、PTS与时间戳管理、音视频同步机制、时钟漂移补偿策略
各位同学，今天我们来聊聊音频系统里最磨人的一个话题——时钟与同步。
说实话，我早年做第一个播放器项目时，觉得音频不就是把数据扔给底层播放吗？结果一跑起来，声音倒是有了，但画面跟声音差了半秒多。用户反馈说“这电影像译制片，嘴型对不上”。嗯，从那以后，我再也不敢小看时钟同步了。
这一章，我们就来拆解AudioFlinger里关于时钟和同步的那些核心机制。
10.1 音频时钟源：系统的心跳
音频时钟源，说白了就是驱动音频数据流动的“心跳”。AudioFlinger里主要有两种时钟源：
- ALSA时钟（硬件时钟）：由声卡驱动提供，基于硬件晶振。精度高，漂移小。
- 系统时钟（CLOCK_MONOTONIC）：由Linux内核维护，适合做时间戳基准。
我个人习惯，在需要精确控制播放节奏的场景下，优先使用ALSA时钟。为什么？因为系统时钟可能被NTP调整或休眠影响，而硬件时钟是独立的。
核心原则：音频数据消费的节奏，必须由硬件时钟驱动。软件只能“跟随”，不能“主导”。
在AudioFlinger的PlaybackThread里，每次写入数据前都会调用getNextWriteTimestamp()，这个时间戳就是基于硬件时钟换算出来的。
10.2 PTS与时间戳管理
PTS（Presentation Time Stamp）是音视频同步的基石。每个音频数据块（通常是一个buffer）都应该携带一个PTS，表示它应该在什么时间被播放。
AudioFlinger里时间戳的管理分两个层面：
- 输入时间戳：来自上层MediaPlayer或解码器，通常是基于系统时钟的绝对时间。
- 输出时间戳：由AudioFlinger在数据写入硬件时生成，基于硬件时钟。
这里有个坑——我曾经遇到过一个case，上层传下来的PTS是视频帧的，音频解码器忘了重新生成自己的PTS，结果音视频直接错位。排查了两天才发现。
注意：音频和视频的PTS必须基于同一个时钟域。如果一个是系统时钟，一个是硬件时钟，必须做转换。
时间戳转换的代码大致长这样：
// 将系统时钟时间戳转换为硬件时钟时间戳
nsecs_t convertSystemToHwClock(nsecs_t systemTime) {
nsecs_t hwTime = systemTime - systemBootTime + hwBootTime;
return hwTime;
}你想想看，如果这个转换做错了，那音视频同步就全乱套了。
10.3 音视频同步机制
音视频同步，业内通常有三种策略：
| 策略 | 原理 | 适用场景 |
|---|---|---|
| 音频为主 | 视频跟随音频时钟 | 直播、通话（人耳对音频更敏感） |
| 视频为主 | 音频跟随视频时钟 | 视频编辑、幻灯片 |
| 外部时钟 | 两者都跟随一个公共时钟 | 多设备同步、专业音视频系统 |
Android默认采用音频为主的策略。为什么？因为人耳对音频的抖动比眼睛对视频的抖动更敏感。你想想看，画面卡一下可能还能接受，但声音断断续续或者变调，那体验就彻底崩了。
在AudioFlinger里，同步逻辑主要在AudioResampler和TimedAudioTrack中实现。当视频帧到达时，会对比当前音频播放位置和视频帧的PTS，如果差距超过阈值，就会触发丢帧或重复帧。
经验之谈：阈值设置很关键。设得太小，系统频繁调整，反而造成抖动；设得太大，用户能感知到不同步。我一般建议音频领先视频不超过40ms，视频领先音频不超过20ms。
10.4 时钟漂移补偿策略
时钟漂移是硬件世界的常态。两个晶振不可能完全一致，哪怕标称都是48kHz，实际跑起来也可能差个几十ppm。
时钟漂移带来的问题很直接：如果音频源和音频消费端的时钟不同步，buffer要么溢出（太快），要么欠载（太慢）。
AudioFlinger的补偿策略主要有三种：
- 重采样（Resampling）：通过调整采样率来匹配时钟。这是最常用的方法。
- 插入/删除样本：在静音段或非关键段插入或删除少量样本。适合低延迟场景。
- 调整播放速度：微调播放速率，比如从1.0x调到1.001x。适合长时间播放。
我个人在项目中用得最多的是重采样。AudioFlinger内置的AudioResampler支持动态调整采样率，而且质量很高。
补偿的流程大致如下：
- 测量硬件时钟和系统时钟的偏差。
- 计算漂移率（ppm）。
- 根据漂移率调整重采样比率。
- 定期校准，防止累积误差。
我曾经在一个车载项目里遇到过极端情况——两个蓝牙设备同时播放，各自的晶振漂移方向相反，结果半小时后偏差达到了一个buffer的长度。最后靠动态重采样加定期校准才搞定。
关键点：时钟漂移补偿不是一次性的，而是一个持续的过程。你需要一个闭环控制系统，不断测量、调整、再测量。
10.5 知识体系总览
下面这张图，我把本章的核心逻辑画出来了。你可以看到，从时钟源到时间戳管理，再到同步策略和漂移补偿，是一条完整的数据流。
从这张图你可以看到，整个同步链路是环环相扣的。任何一个环节出问题，最终表现就是音画不同步。
10.6 实战建议
最后，我给大家几个实战中的建议：
- 日志要打全：把每次PTS对比、漂移率、调整量都打出来。排查问题时这些日志就是救命稻草。
- 不要迷信硬件：硬件时钟也会漂移，只是漂移率小一些。该做的补偿一样不能少。
- 测试要覆盖长时间播放：很多同步问题在播放前5分钟看不出来，跑半小时以上才暴露。
小技巧：在开发阶段，可以故意给一个时钟源注入漂移（比如每10秒加1ms），来验证你的补偿逻辑是否健壮。我管这叫“压力测试同步”。
好了，关于音频时钟与同步，我们就聊到这里。记住一句话：同步不是一次性的对齐，而是持续的跟随。理解了这一点，你就能驾驭AudioFlinger里最复杂的这部分逻辑。
公众号:蓝海资料掘金营，微信deep3321