首先是下面會用到的
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。