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

看板Audiophile作者時間9月前 (2023/07/15 00:01), 9月前編輯推噓8(8推 0噓 47→)
留言55則, 8人參與, 9月前最新討論串5/5 (看更多)
首先是下面會用到的 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
→
07/15 05:13, 9月前 , 1F
Quote：「VAD 就是聲卡 使用ptp來的校准 在正確的時間
07/15 05:13, 1F
→
07/15 05:13, 9月前 , 2F
生成定時器中斷」：Mac Win Linux 三個平台的 AES67 driv
07/15 05:13, 2F
→
07/15 05:13, 9月前 , 3F
er 都不會對系統時鐘校準，生成定時器中斷的時間是系統
07/15 05:13, 3F
→
07/15 05:13, 9月前 , 4F
時間。這點可由open source 的 Linux driver 窺知。Mac
07/15 05:13, 4F
→
07/15 05:14, 9月前 , 5F
上能使用的網卡除了外接的有機會有PHC & HW TS，其餘均
07/15 05:14, 5F
→
07/15 05:14, 9月前 , 6F
未有PHC + HW TS。加上 macOS 從未打算支援 PTP，因此 VA
07/15 05:14, 6F
→
07/15 05:14, 9月前 , 7F
D 的 PTP implementation 為 SW slave only；Linux 雖說
07/15 05:14, 7F
→
07/15 05:14, 9月前 , 8F
核心（網卡驅動）支援 PHC & HW TS，但其 AES67 driver
07/15 05:14, 8F
→
07/15 05:14, 9月前 , 9F
也從不使用 PHC & HW TS，也是 SW slave only 並且也不
07/15 05:14, 9F
→
07/15 05:14, 9月前 , 10F
做時間校準。Win 的 MAD 就比較複雜，外部器材必須要設定
07/15 05:14, 10F
→
07/15 05:14, 9月前 , 11F
為 ASIO clock，MAD 才鎖得住，但鎖歸鎖，Merging 建議安
07/15 05:14, 11F
→
07/15 05:14, 9月前 , 12F
全的 buffer size 卻是 192~256 frames（依據 1fs size）
07/15 05:14, 12F
→
07/15 05:14, 9月前 , 13F
。macOS 最小 frame size 是 16，Linux 最小 frame 32（
07/15 05:14, 13F
→
07/15 05:14, 9月前 , 14F
若設定低於 32 Ravenna daemon 會自動跳回 default 128）
07/15 05:14, 14F
→
07/15 05:14, 9月前 , 15F
。
07/15 05:14, 15F
→
07/15 05:39, 9月前 , 16F
從Linux alsa lkm m_dTIC_CurrentPeriod往回找即可看到
07/15 05:39, 16F
→
07/15 05:39, 9月前 , 17F
定時器上的簡單的同步，VAD隔離了系統時鐘和時鐘偏差
07/15 05:39, 17F
→
07/15 05:58, 9月前 , 18F
那僅是 syntonization
07/15 05:58, 18F
推
07/15 06:59, 9月前 , 19F
所以不是"用電腦播放"的人都適用齁~~
07/15 06:59, 19F
→
07/15 07:00, 9月前 , 20F
這一大串清楚說明了音樂到耳朵前的過程，謝謝分享
07/15 07:00, 20F
推
07/15 07:37, 9月前 , 21F
現在的串流機大都也是在ARM平台上跑Linux的電腦，看功能跟串
07/15 07:37, 21F
→
07/15 07:37, 9月前 , 22F
流的通訊協定做類似的事
07/15 07:37, 22F
推
07/15 11:13, 9月前 , 23F
感謝分享！！ 本文值得2個m。
07/15 11:13, 23F
→
07/15 11:19, 9月前 , 24F
這篇文章，是我研究音響來，一直想知道的整串播放流程的細
07/15 11:19, 24F
→
07/15 11:20, 9月前 , 25F
節。經過這麼多年，感謝sunyanwen大大實現我的心願。
07/15 11:20, 25F
推
07/15 11:56, 9月前 , 26F
感謝科普
07/15 11:56, 26F
推
07/15 11:57, 9月前 , 27F
其實兩件事 影響硬體運作的時鐘(時脈) 跟用來對時(同步)
07/15 11:57, 27F
→
07/15 11:58, 9月前 , 28F
我感覺 e大一直沒能分清楚什麼是什麼
07/15 11:58, 28F
→
07/15 11:59, 9月前 , 29F
就像上面提到 ASIO、ASIO&WASAPI 都只是軟體層的 API
07/15 11:59, 29F
→
07/15 12:00, 9月前 , 30F
一個軟體運作，跟硬體 clock 是不直接掛鈎的
07/15 12:00, 30F
→
07/15 12:08, 9月前 , 31F
07/15 12:08, 31F
→
07/15 12:08, 9月前 , 32F
07/15 12:08, 32F
→
07/15 12:09, 9月前 , 33F
同步的 timestamp 是放在 Layer5 RTP Header 中，這代表的
07/15 12:09, 33F
→
07/15 12:12, 9月前 , 34F
意義是什麼，稍理解 OSI 7層的人都應該能理解
07/15 12:12, 34F
→
07/15 12:14, 9月前 , 35F
時間對齊和同步速度，並不是在傳輸過程中達成的
07/15 12:14, 35F
推
07/15 15:01, 9月前 , 36F
推，這系列文，長知識
07/15 15:01, 36F
補充: 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
→
07/15 22:14, 9月前 , 37F
Quote:「可見VAD的timer是貼著標準時間走的」：我一直是
07/15 22:14, 37F
→
07/15 22:14, 9月前 , 38F
這麼表示的…
07/15 22:14, 38F
推
07/15 23:47, 9月前 , 39F
sun大以後多發文啊~~~
07/15 23:47, 39F
補充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
→
07/16 06:36, 9月前 , 40F
Quote:「OS取準確時間代價太大」：所以我 proposed 用 80
07/16 06:36, 40F
→
07/16 06:36, 9月前 , 41F
2.1AS layer 2 對電腦系統對時（layer 3 被 Ravenna 佔
07/16 06:36, 41F
→
07/16 06:36, 9月前 , 42F
用），無法 802.1AS 的系統則使用 local NTP 對時（同一
07/16 06:36, 42F
→
07/16 06:36, 9月前 , 43F
個時鐘源）。這樣的代價並不高且有效。
07/16 06:36, 43F
→
07/16 07:07, 9月前 , 44F
當然怎樣對時都沒問題，但即便對時也還是要經過VAD PTP
07/16 07:07, 44F
→
07/16 07:07, 9月前 , 45F
的drift rate校正，因為始終要同步到GM，想想看工作室
07/16 07:07, 45F
→
07/16 07:07, 9月前 , 46F
的GM如果沒用GPS時間且偏差很大，不經PTP校正+NTP到與G
07/16 07:07, 46F
→
07/16 07:07, 9月前 , 47F
M不同步的時鐘=破壞音頻時鐘，對時目的還是為了同步，
07/16 07:07, 47F
→
07/16 07:07, 9月前 , 48F
只不過系統內的GM才是真正的參考
07/16 07:07, 48F
推
07/16 08:03, 9月前 , 49F
Quote:「系統內的GM才是真正的參考」：是，完全同意。我
07/16 08:03, 49F
→
07/16 08:03, 9月前 , 50F
是用AES67系統內的GPS PTP GMC當唯一時鐘源（e810），用
07/16 08:03, 50F
→
07/16 08:03, 9月前 , 51F
多網口做出不同profile/layer/protocol給各應用區；e810
07/16 08:03, 51F
→
07/16 08:03, 9月前 , 52F
設計上只有一個PHC給四個網口共用，其中：一個網口UDP/E2
07/16 08:03, 52F
→
07/16 08:03, 9月前 , 53F
E AES67 profile給Ravenna network，一個網口802.1AS走la
07/16 08:03, 53F
→
07/16 08:03, 9月前 , 54F
yer 2，一個網口設定具HW TS的NTP server。另因預算不足
07/16 08:03, 54F
→
07/16 08:03, 9月前 , 55F
交換器只能用便宜的具TC能力的M4250。
07/16 08:03, 55F
‣ 更多 sunyanwen 的文章
文章代碼(AID): #1aiN5cMR (Audiophile)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 sunyanwen 的文章
文章代碼(AID): #1aiN5cMR (Audiophile)