作者sunyanwen ()
看板Audiophile
标题Re: [心得] 运用 Chrony 对时工具提升音讯品质
时间Sat Jul 15 00:01:36 2023
首先是下面会用到的
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做时钟源，所以很难消掉
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 132.226.0.200 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Audiophile/M.1689350502.A.59B.html
1F：→ elguapo: Quote：「VAD 就是声卡 使用ptp来的校准 在正确的时间 07/15 05:13
2F：→ elguapo: 生成定时器中断」：Mac Win Linux 三个平台的 AES67 driv 07/15 05:13
3F：→ elguapo: er 都不会对系统时钟校准，生成定时器中断的时间是系统 07/15 05:13
4F：→ elguapo: 时间。这点可由open source 的 Linux driver 窥知。Mac 07/15 05:13
5F：→ elguapo: 上能使用的网卡除了外接的有机会有PHC & HW TS，其余均 07/15 05:14
6F：→ elguapo: 未有PHC + HW TS。加上 macOS 从未打算支援 PTP，因此 VA 07/15 05:14
7F：→ elguapo: D 的 PTP implementation 为 SW slave only；Linux 虽说 07/15 05:14
8F：→ elguapo: 核心（网卡驱动）支援 PHC & HW TS，但其 AES67 driver 07/15 05:14
9F：→ elguapo: 也从不使用 PHC & HW TS，也是 SW slave only 并且也不 07/15 05:14
10F：→ elguapo: 做时间校准。Win 的 MAD 就比较复杂，外部器材必须要设定 07/15 05:14
11F：→ elguapo: 为 ASIO clock，MAD 才锁得住，但锁归锁，Merging 建议安 07/15 05:14
12F：→ elguapo: 全的 buffer size 却是 192~256 frames（依据 1fs size） 07/15 05:14
13F：→ elguapo: 。macOS 最小 frame size 是 16，Linux 最小 frame 32（ 07/15 05:14
14F：→ elguapo: 若设定低於 32 Ravenna daemon 会自动跳回 default 128） 07/15 05:14
15F：→ elguapo: 。 07/15 05:14
16F：→ sunyanwen: 从Linux alsa lkm m_dTIC_CurrentPeriod往回找即可看到 07/15 05:39
17F：→ sunyanwen: 定时器上的简单的同步，VAD隔离了系统时钟和时钟偏差 07/15 05:39
18F：→ elguapo: 那仅是 syntonization 07/15 05:58
19F：推 greg7575: 所以不是"用电脑播放"的人都适用齁~~ 07/15 06:59
20F：→ greg7575: 这一大串清楚说明了音乐到耳朵前的过程，谢谢分享 07/15 07:00
21F：推 xoy: 现在的串流机大都也是在ARM平台上跑Linux的电脑，看功能跟串 07/15 07:37
22F：→ xoy: 流的通讯协定做类似的事 07/15 07:37
23F：推 djboy: 感谢分享！！ 本文值得2个m。 07/15 11:13
24F：→ djboy: 这篇文章，是我研究音响来，一直想知道的整串播放流程的细 07/15 11:19
25F：→ djboy: 节。经过这麽多年，感谢sunyanwen大大实现我的心愿。 07/15 11:20
26F：推 danisaku: 感谢科普 07/15 11:56
27F：推 Oswyn: 其实两件事 影响硬体运作的时钟(时脉) 跟用来对时(同步) 07/15 11:57
28F：→ Oswyn: 我感觉 e大一直没能分清楚什麽是什麽 07/15 11:58
29F：→ Oswyn: 就像上面提到 ASIO、ASIO&WASAPI 都只是软体层的 API 07/15 11:59
30F：→ Oswyn: 一个软体运作，跟硬体 clock 是不直接挂鈎的 07/15 12:00
33F：→ Oswyn: 同步的 timestamp 是放在 Layer5 RTP Header 中，这代表的 07/15 12:09
34F：→ Oswyn: 意义是什麽，稍理解 OSI 7层的人都应该能理解 07/15 12:12
35F：→ Oswyn: 时间对齐和同步速度，并不是在传输过程中达成的 07/15 12:14
36F：推 iitze: 推，这系列文，长知识 07/15 15:01
补充:
VAD中slave clock对时方法
https://i.imgur.com/cd7GuOH.png
PTP求得drift rate,定时器中断(本机时间+1ms/drift rate)将落在标准时间+1ms附近，
下次中断就是在(标准时间+1ms附近)的本机时间+(1ms/drift rate)
为防止偏差过大，在同步间隔R时会重新生成drift rate
可见VAD的timer是贴着标准时间走的
media clock只有在DAC/ADC边缘才是真实的时钟信号，
可以映射到GM绝对时间，但AES67没有严格要求相位同步
RTP中的timestamp实际是media clock计数器，比如48000khz,1ms buffer,
GM时间每ms应该有1个RTP Packet,timestamp就应该加48，并没有绝对时间
每个slave的每秒都有1000个ms(被同步约束)
只要满足同步，就能在jitter buffer还原回精确的sample clock & sample
这期间VAD完全不知道每个sample在什麽时间生成，因为他是burst的，时间由GM保证
实际上同步建立在音频时钟+jitter buffer上，
除PTP packet外没有其他packet有真正的timestamp
※ 编辑: sunyanwen (132.226.0.200 日本), 07/15/2023 18:11:25
37F：→ elguapo: Quote:「可见VAD的timer是贴着标准时间走的」：我一直是 07/15 22:14
38F：→ elguapo: 这麽表示的… 07/15 22:14
39F：推 djboy: sun大以後多发文啊~~~ 07/15 23:47
补充2:
1ms jitter buffer意味着1ms delay，和其他设备align间隔也是1ms，
声卡工作在burst模式，因为不能同步时钟到AD/DA，这意味着相位要求几乎没有
频率同步不需要delay measurement,故可以使用SW PTP(不需要hw timestamp)
这样就只需要接收sync,同时用相对时间差计算drift rate
实际上VAD也没有发任何ptp包出去
SW PTP可以满足1ms要求，并且不需要额外硬件，是VAD首选
sample instant alignment，也就是标准(GM)时间对AES67的影响
Media Clock在VAD中，因为很难得到精确时间信息(1s/48000,scheduler)
声卡的burst播放也不会在准确的时刻写入sample
所以VAD与GM时间同步，播放设备按GM时钟生成采样率播放，理想情况下就是bit perfect
真正有差别的地方在多路AD/DA，mixer上
具有相同RTP timestamp的sample要在相同的时刻sample/playback，(AES11的+-5%)
这个时刻由PTP GM保证，通过hw timestamp+servo+dpll+apll生成sample edge，
确保所有相位同步的设备都具有非常接近的相位，必须要用HW PTP且需要很多额外组件
这个问题可以很大，但优势也在这里，用了GPS，全世界可以一起录
顺便就可以提供给嵌入式系统一个时钟源，系统时间和GM完全一样，
但系统时间和音频时钟依旧没有关联，
Media Clock绑定到GM时间，要求绝对准确，OS取准确时间代价太大
最後 ALC NetworX VAD 提供了system time sync功能, 需要HW PTP，
Intel旧网卡基本都可以用，可以体验看看
※ 编辑: sunyanwen (132.226.0.200 日本), 07/16/2023 05:29:00
40F：→ elguapo: Quote:「OS取准确时间代价太大」：所以我 proposed 用 80 07/16 06:36
41F：→ elguapo: 2.1AS layer 2 对电脑系统对时（layer 3 被 Ravenna 占 07/16 06:36
42F：→ elguapo: 用），无法 802.1AS 的系统则使用 local NTP 对时（同一 07/16 06:36
43F：→ elguapo: 个时钟源）。这样的代价并不高且有效。 07/16 06:36
44F：→ sunyanwen: 当然怎样对时都没问题，但即便对时也还是要经过VAD PTP 07/16 07:07
45F：→ sunyanwen: 的drift rate校正，因为始终要同步到GM，想想看工作室 07/16 07:07
46F：→ sunyanwen: 的GM如果没用GPS时间且偏差很大，不经PTP校正+NTP到与G 07/16 07:07
47F：→ sunyanwen: M不同步的时钟=破坏音频时钟，对时目的还是为了同步， 07/16 07:07
48F：→ sunyanwen: 只不过系统内的GM才是真正的参考 07/16 07:07
49F：推 elguapo: Quote:「系统内的GM才是真正的参考」：是，完全同意。我 07/16 08:03
50F：→ elguapo: 是用AES67系统内的GPS PTP GMC当唯一时钟源（e810），用 07/16 08:03
51F：→ elguapo: 多网口做出不同profile/layer/protocol给各应用区；e810 07/16 08:03
52F：→ elguapo: 设计上只有一个PHC给四个网口共用，其中：一个网口UDP/E2 07/16 08:03
53F：→ elguapo: E AES67 profile给Ravenna network，一个网口802.1AS走la 07/16 08:03
54F：→ elguapo: yer 2，一个网口设定具HW TS的NTP server。另因预算不足 07/16 08:03
55F：→ elguapo: 交换器只能用便宜的具TC能力的M4250。 07/16 08:03