Re: [心得] 運用 Chrony 對時工具提升音訊品質

首先是下面會用到的 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://www.ptt.cc/bbs/Audiophile/M.1689350502.A.59B.html