PTT評價

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

看板Audiophile標題Re: [心得] 運用 Chrony 對時工具提升音訊品質作者
sunyanwen
()
時間推噓 8 推:8 噓:0 →:47

首先是下面會用到的
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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 132.226.0.200 (日本)
PTT 網址

elguapo07/15 05:13Quote:「VAD 就是聲卡 使用ptp來的校准 在正確的時間

elguapo07/15 05:13生成定時器中斷」:Mac Win Linux 三個平台的 AES67 driv

elguapo07/15 05:13er 都不會對系統時鐘校準,生成定時器中斷的時間是系統

elguapo07/15 05:13時間。這點可由open source 的 Linux driver 窺知。Mac

elguapo07/15 05:14 上能使用的網卡除了外接的有機會有PHC & HW TS,其餘均

elguapo07/15 05:14未有PHC + HW TS。加上 macOS 從未打算支援 PTP,因此 VA

elguapo07/15 05:14D 的 PTP implementation 為 SW slave only;Linux 雖說

elguapo07/15 05:14核心(網卡驅動)支援 PHC & HW TS,但其 AES67 driver

elguapo07/15 05:14 也從不使用 PHC & HW TS,也是 SW slave only 並且也不

elguapo07/15 05:14做時間校準。Win 的 MAD 就比較複雜,外部器材必須要設定

elguapo07/15 05:14為 ASIO clock,MAD 才鎖得住,但鎖歸鎖,Merging 建議安

elguapo07/15 05:14全的 buffer size 卻是 192~256 frames(依據 1fs size)

elguapo07/15 05:14。macOS 最小 frame size 是 16,Linux 最小 frame 32(

elguapo07/15 05:14若設定低於 32 Ravenna daemon 會自動跳回 default 128)

elguapo07/15 05:14

sunyanwen07/15 05:39從Linux alsa lkm m_dTIC_CurrentPeriod往回找即可看到

sunyanwen07/15 05:39定時器上的簡單的同步,VAD隔離了系統時鐘和時鐘偏差

elguapo07/15 05:58那僅是 syntonization

greg757507/15 06:59所以不是"用電腦播放"的人都適用齁~~

greg757507/15 07:00這一大串清楚說明了音樂到耳朵前的過程,謝謝分享

xoy07/15 07:37現在的串流機大都也是在ARM平台上跑Linux的電腦,看功能跟串

xoy07/15 07:37流的通訊協定做類似的事

djboy07/15 11:13感謝分享!! 本文值得2個m。

djboy07/15 11:19這篇文章,是我研究音響來,一直想知道的整串播放流程的細

djboy07/15 11:20節。經過這麼多年,感謝sunyanwen大大實現我的心願。

danisaku07/15 11:56感謝科普

Oswyn07/15 11:57其實兩件事 影響硬體運作的時鐘(時脈) 跟用來對時(同步)

Oswyn07/15 11:58我感覺 e大一直沒能分清楚什麼是什麼

Oswyn07/15 11:59就像上面提到 ASIO、ASIO&WASAPI 都只是軟體層的 API

Oswyn07/15 12:00一個軟體運作,跟硬體 clock 是不直接掛鈎的

Oswyn07/15 12:09同步的 timestamp 是放在 Layer5 RTP Header 中,這代表的

Oswyn07/15 12:12意義是什麼,稍理解 OSI 7層的人都應該能理解

Oswyn07/15 12:14時間對齊和同步速度,並不是在傳輸過程中達成的

iitze07/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

elguapo07/15 22:14Quote:「可見VAD的timer是貼著標準時間走的」:我一直是

elguapo07/15 22:14這麼表示的…

djboy07/15 23:47sun大以後多發文啊~~~

補充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

elguapo07/16 06:36Quote:「OS取準確時間代價太大」:所以我 proposed 用 80

elguapo07/16 06:362.1AS layer 2 對電腦系統對時(layer 3 被 Ravenna 佔

elguapo07/16 06:36用),無法 802.1AS 的系統則使用 local NTP 對時(同一

elguapo07/16 06:36個時鐘源)。這樣的代價並不高且有效。

sunyanwen07/16 07:07當然怎樣對時都沒問題,但即便對時也還是要經過VAD PTP

sunyanwen07/16 07:07的drift rate校正,因為始終要同步到GM,想想看工作室

sunyanwen07/16 07:07的GM如果沒用GPS時間且偏差很大,不經PTP校正+NTP到與G

sunyanwen07/16 07:07M不同步的時鐘=破壞音頻時鐘,對時目的還是為了同步,

sunyanwen07/16 07:07只不過系統內的GM才是真正的參考

elguapo07/16 08:03Quote:「系統內的GM才是真正的參考」:是,完全同意。我

elguapo07/16 08:03是用AES67系統內的GPS PTP GMC當唯一時鐘源(e810),用

elguapo07/16 08:03多網口做出不同profile/layer/protocol給各應用區;e810

elguapo07/16 08:03設計上只有一個PHC給四個網口共用,其中:一個網口UDP/E2

elguapo07/16 08:03E AES67 profile給Ravenna network,一個網口802.1AS走la

elguapo07/16 08:03yer 2,一個網口設定具HW TS的NTP server。另因預算不足

elguapo07/16 08:03交換器只能用便宜的具TC能力的M4250。