首先是下面会用到的
OS和用户可以用到的时钟:
clock realtime -> 可以被ntp搞到逆时针转的
clock monotonic -> 只能顺时针转，但可以因ntp而调整转速(速率)
clock monotonic raw ->只能顺时针转 不受ntp影响
以上三个共同点 依赖系统时钟源
ptp clock ->在合理的系统上会和PTP GM运行在相同速率
drifted clock 通常还是会有相对稳定的速率
有小的的drift rate=>去掉drift rate就变成比较精确的时钟
TSC:CPU温度变化剧烈，但TSC来源PLL的REF晶振温度变化不大
unstable clock 时间在很短时间变化,倒退,停止
通常不会被OS选为可靠的系统时钟
ptp clock，用数次sync的时间差除以本地时间差会得到drift rate
结合drifted clock就可以得到相对精确且稳定的时钟(10kHz+)
PTP GM在AES67里可以当做Word Sync, Wall Clock
PTP Slave Clock可以经DPLL锁相到VCO/VCXO，
divide到sample rate可得Media Clock，这种方式得到的是连续时钟，
也可按上面方法得drift rate然后生成timer，
断续的clock不能拿来sample 但依旧可以为sample编号(Media Clock)
这种方式生成的是burst间隔，通常用来按buffer size生成timer
audio file (一大锅米饭)
burst transfer (一大勺=32口米饭)
continuous streaming (一口一口吃)
jitter buffer: https://bit.ly/44O1PVL
借助jitter buffer(碗和大小勺子)把burst transfer变成continuous streaming
声卡上有一个小缓冲区(碗)
声卡的控制器(大小勺子)在晶振的固定频率(continuous)下喂给dac数据(一小勺)
碗快空了就通知主机或者自己再添一大勺饭到碗里(burst)
只向主机要一小勺会生气!! (浪费bus)
会用到的结束
举例子 播MP3文件
通常mp3 decoder通常会耗尽CPU把mp3转回pcm数据并写入声卡
(对，burst，没有速率控制)
但声卡的缓冲区很小且消耗速度是固定的,
decoder必须先暂停然后等待声卡告知自己的缓冲区空出一部分
然后再次写入直到播放完毕
此时MP3的总播放长度与dac时钟速度成比例
短期看播放速率是毛刺状(burst)，长期看播放速率固定在dac时钟速率
还可以看到主机的所有时间都和播放无关,
实际上正在使用声卡提供的指示来计算时间.
VAD 就是声卡
使用ptp来的校准 在正确的时间生成定时器中断
~~~~ ~~~~~~~~~~
(burst间隔，1/sample rate * buffer size, 1ms级)
可以看做把声卡晶振的固定频率连接到VAD做时钟(固定的消耗速度)
主机会一次填满缓冲区,定时器提前或延后都不会影响音频数据的完整性
~~~~~~~~~~~~~~
配合接收端jitter buffer把burst数据平滑到continuous，
dac端使用dpll同步到和burst长期速率一致的GM时钟，
burst间隔取决于选择的缓冲区大小，
以32个sample 44.1k为例
只要在和GM同步的timer时间的+-0.7ms内发包，jitter buffer就能维持精确输出.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VAD最大PTP校正能力是+-1.2x系统时间 外加最短0.125秒生成一次校正，
macOS上的VAD默认使用"clock monotonic"形态的时钟，
可以受ntp影响，但周期长于VAD PTP的校正，且校正量通常远小于jitter容忍范围
除了可能造成解锁外功能可以忽略
如果系统时钟波动过大或者调度器没办法在jitter容忍范围内把RTP包发到接收器
Merging的VAD会在system.log和dmesg里留下痕迹
使用中最大的问题是调度器导致定时器fire过晚，ms级
要提到的还有之所以其他设备的delta很小，
是因为他们的系统会选择ptp做时钟源，
系统时间紧密贴合PTP GM，
macOS没法用PTP做时钟源，所以很难消掉

Quote：“VAD 就是声卡 使用ptp来的校准 在正确的时间生成定时器中断”：Mac Win Linux 三个平台的 AES67 driver 都不会对系统时钟校准，生成定时器中断的时间是系统时间。这点可由open source 的 Linux driver 窥知。Mac上能使用的网卡除了外接的有机会有PHC & HW TS，其余均未有PHC + HW TS。加上 macOS 从未打算支援 PTP，因此 VAD 的 PTP implementation 为 SW slave only；Linux 虽说核心（网卡驱动）支援 PHC & HW TS，但其 AES67 driver也从不使用 PHC & HW TS，也是 SW slave only 并且也不做时间校准。Win 的 MAD 就比较复杂，外部器材必须要设定为 ASIO clock，MAD 才锁得住，但锁归锁，Merging 建议安全的 buffer size 却是 192~256 frames（依据 1fs size）。macOS 最小 frame size 是 16，Linux 最小 frame 32（若设定低于 32 Ravenna daemon 会自动跳回 default 128）。

从Linux alsa lkm m_dTIC_CurrentPeriod往回找即可看到定时器上的简单的同步，VAD隔离了系统时钟和时钟偏差

那仅是 syntonization

所以不是"用电脑播放"的人都适用齁~~这一大串清楚说明了音乐到耳朵前的过程，谢谢分享

现在的串流机大都也是在ARM平台上跑Linux的电脑，看功能跟串流的通讯协定做类似的事

感谢分享！！ 本文值得2个m。这篇文章，是我研究音响来，一直想知道的整串播放流程的细节。经过这么多年，感谢sunyanwen大大实现我的心愿。

感谢科普

其实两件事 影响硬件运作的时钟(时脉) 跟用来对时(同步)我感觉 e大一直没能分清楚什么是什么就像上面提到 ASIO、ASIO&WASAPI 都只是软件层的 API一个软件运作，跟硬件 clock 是不直接挂钩的https://i.imgur.com/sf1EZ2s.jpghttps://i.imgur.com/OxZFlRp.jpg同步的 timestamp 是放在 Layer5 RTP Header 中，这代表的意义是什么，稍理解 OSI 7层的人都应该能理解时间对齐和同步速度，并不是在传输过程中达成的

推，这系列文，长知识

Quote:“可见VAD的timer是贴著标准时间走的”：我一直是这么表示的…

sun大以后多发文啊~~~

Quote:“OS取准确时间代价太大”：所以我 proposed 用 802.1AS layer 2 对电脑系统对时（layer 3 被 Ravenna 占用），无法 802.1AS 的系统则使用 local NTP 对时（同一个时钟源）。这样的代价并不高且有效。

当然怎样对时都没问题，但即便对时也还是要经过VAD PTP的drift rate校正，因为始终要同步到GM，想想看工作室的GM如果没用GPS时间且偏差很大，不经PTP校正+NTP到与GM不同步的时钟=破坏音频时钟，对时目的还是为了同步，只不过系统内的GM才是真正的参考

Quote:“系统内的GM才是真正的参考”：是，完全同意。我是用AES67系统内的GPS PTP GMC当唯一时钟源（e810），用多网口做出不同profile/layer/protocol给各应用区；e810设计上只有一个PHC给四个网口共用，其中：一个网口UDP/E2E AES67 profile给Ravenna network，一个网口802.1AS走layer 2，一个网口设定具HW TS的NTP server。另因预算不足交换器只能用便宜的具TC能力的M4250。