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

看板Audiophile作者 (HPHT Synthesized)時間10月前 (2023/07/10 21:09), 9月前編輯推噓40(41推 1噓 113→)
留言155則, 30人參與, 9月前最新討論串1/5 (看更多)
「紊亂的電腦系統時鐘，經過對時調節（realtime clock）到接近 AES11 Grade 2 的精度，進而增進電腦音訊品質。」 自從開始使用 Ravenna/AES67 AoIP 之後，對於時間的準確度也越來越要求；不久 前收了一張具備 GPS 接收器的 Intel E810-XXVDA4TGG1 網路卡，作為我的 AES67 的主時鐘，並將開箱文貼到 audiophilestyle 網站： https://tinyurl.com/3p8ccjv2 本來想在 ptt 補充一下中文的部分，但後來發現有更值得討論的內容，遂決定先來 寫關於電腦作業系統時鐘的校對問題。 以 48000Hz 取樣率的音樂來說好了，相信很多燒友應該會認為是 48000Hz 的「 載波」在傳遞音訊。若有讀過 AES3 以及 AES67 的規範，其實音訊的傳遞是「每秒 傳送 48000 個取樣值」，若切更細一點，以 AES67 來說，數位音訊是每 1ms 傳送 48 個取樣值到目的地。 「若系統時鐘不穩定，充滿 jitter 而且偏移嚴重，那麼這個 1ms 還會是 1ms 嗎？」 ——這是我開始自己建構 AES67 主時鐘的時候不斷思考的問題。 成功的將 Intel E810 設定為我的 AES67 主時鐘之後，也嘗試將這張網卡當成我的 HQPlayer Embedded 伺服器的主鐘，機制是： 1. 依據 GPS 1PPS 信號 rising edge 擷取 GPS 模組解出的 NMEA 訊息 -> 2. 把 NMEA 更新至網卡上的 PTP hardware clock -> 3. 運用 PTP hardware clock 去同步系統時鐘 CLOCK_REALTIME 以及 AES67 的器材。 經過這樣的對時，HQPe 主機的時間精度可以達 +-10ns 範圍！個人發現 HQPe PCM 的升頻變好聽很多，毛躁感降低不少，慢慢的也懶得升頻 DSD 了。 https://imgur.com/E1aTEZm.jpg
後來再進一步將我的 Fitlet3 NAA 用光纖掛上 E810 的其中一個 SFP28 port， 用同個 PTP hardware clock，傳送 layer 2 的 802.1AS gPTP 的對時資料給 Fitlet3。 https://imgur.com/etMHOn7.jpg
Fitlet3 的 CLOCK_REALTIME 雖然沒有很好，但精度還是能摧到 +-30ns，與 HQPe server 同步後的聽感是，空間的殘響尾韻更顯著且又長了一點！ 沒想到電腦主機正時之後的音訊品質，其改善幅度大到可以複製給來訪的朋友分辨， 所以乾脆愛屋及烏，把沒有辦法做 PTP 對時的電腦用 NTP 伺服器對時看看，結果 也是能得到很大的幫助！ 我的 Atmos music 有 98% 是來自 Apple Music，將來源 Mac Mini M1 電腦用 本地端的 NTP server 做密集對時之後可達 <+-10us，Apple Music Atmos 定位精確度提升，尤其聽大編制的交響樂或大合唱，混亂感降低很多。 因此我想在這篇文章先介紹 Chrony 這個工具給諸君試看看。 Chrony 在 Linux 是家喻戶曉的對時工具，可以手動選擇離自己家最近的 NTP 伺服器，也能手動改動對時的次數頻率。 macOS 已經有 GUI 版，解壓縮立刻能執行： https://whatroute.net/chronycontrol.html 第一次執行 ChronyControl 會提醒您將系統的自動對時關閉，畢竟兩個對時軟體 同時執行會打架，造成時鐘更紊亂。 Chrony 的介面很容易閱讀，跟 Linux 的 chronyc 一模一樣： https://imgur.com/JXzcrkR.jpg
由於預設的伺服器通常比較「遠」（延遲較高），以個人經驗來說，最近的 NTP 伺服器理當是本地端的，其次是 ISP 提供的（但 ISP 提供的 NTP 伺服器階層可能 只到 Stratum 2）；最好的 NTP 伺服器當是國家提供的，是直接和原子鐘對時的 Stratum 1 等級。 我國設立的 NTP 伺服器是這幾個： tock.stdtime.gov.tw watch.stdtime.gov.tw time.stdtime.gov.tw clock.stdtime.gov.tw tick.stdtime.gov.tw 可以用編輯的方式將這些伺服器鍵入 Chrony 的設定檔（按下 ChronyControl 視窗 左上角齒輪就會出現文字編輯器）： https://imgur.com/uM9ZbaK.jpg
按下右下角 Check Syntax 按鈕之後，只要文法沒錯誤，就能繼續按最右邊的 Install Config。 這樣 Chrony 就開始抓可用的 NTP 伺服器，並且選擇誤差最小的那個為主要對時 對象。 由於系統時鐘很快就會歪掉，所以若要長時間保持在 AES11 Grade 2 +-10ppm （+-10us），那麼就必須要增加對時頻率；為了避免被 NTP server 視為惡意行為 （過度的 polling 可能會被判斷為 DDoS），個人建議對時頻率別太緊密，大約 10~30s 範圍都能接受。 若觀察到有理想的 NTP server 在附近，那麼就能在 Chrony 設定檔指定該台伺服 器對時的頻率，寫上： server watch.stdtime.gov.tw minpoll 4 maxpoll 4 prefer 這段設定的意思是將 watch.stdtime.gov.tw 這台 NTP 伺服器當成我的最愛，然後 每 16 秒向她送出對時申請。 ChronyControl 有繪圖功能，按下視窗上緣的 Live Tracking 按鈕，可以觀察開始 對時之後系統時鐘的修正狀態： https://imgur.com/gRrAVjF.jpg
主要看橘色的線，是代表系統時間均值，以截圖來看，我的 MBP13" 經過對時可以 達到並穩定在 AES11 Grade 2 +-10ppm 的要求了。 由於我對 Windows 作業系統工具不是很熟，增加對時頻率的方法可能要請版上高人 補完了... Orz 希望這個 Linux or macOS 系統設定的變動能為「以電腦為主要播放器材」的版友 帶來助益 :-) 「對時，是為了要有：一致的一秒長度、一致的一秒起點以及一致的曆日」。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.96.60 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1688994586.A.585.html ※ elguapo:轉錄至看板 Headphone 07/10 21:15
推
07/10 21:47, 9月前 , 1F
感謝造福眾小資 已設置且感受明顯
07/10 21:47, 1F
推
07/10 21:51, 9月前 , 2F
雖然看不懂還是推
07/10 21:51, 2F
推
07/10 21:52, 9月前 , 3F
謝分享 順便問apple music 在mac還是不會自動抓分辨率嗎
07/10 21:52, 3F
噓
07/10 22:04, 9月前 , 4F
(取樣率
07/10 22:04, 4F
推
07/10 22:06, 9月前 , 5F
補推
07/10 22:06, 5F
目前還是不行... sorry :-( ※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:11:10
推
07/10 22:10, 9月前 , 6F
這樣效果有比外接主時鐘還好嗎？
07/10 22:10, 6F
好奇問，請問市售哪台電腦可以接鐘？抱歉我可能有盲點... ※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:18:41
推
07/10 22:30, 9月前 , 7F
只會win10手動對時完快速聽歌
07/10 22:30, 7F
→
07/10 22:46, 9月前 , 8F
對時完 不還是照自己的時鐘跑嗎:D
07/10 22:46, 8F
AES11 有規範，音訊節點與節點的銜接誤差要小於 +-50ppm。基本上電腦的 CLOCK_REALT IME 在 free clock 狀態是無法滿足條件的。 正時後就有機會能符合這些要求。 ※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:52:51
推
07/10 23:11, 9月前 , 9F
如果有時鐘 感覺自己做個NTP伺服器 給所有設備
07/10 23:11, 9F
推
07/10 23:27, 9月前 , 10F
推 但我疑惑的點是 對時以後 晶振的品質還是一樣沒有改變啊?
07/10 23:27, 10F
電腦主機板的時鐘品質並不理想，且不考慮 holdover 性能，因此需要將對時的頻率提高 ，令時鐘維持在理想的誤差範圍內。
→
07/10 23:27, 9月前 , 11F
但為了以後演場會更好搶票 我還是做了正時XD
07/10 23:27, 11F
推
07/10 23:39, 9月前 , 12F
推，感覺很有趣，晚點來試試
07/10 23:39, 12F
→
07/10 23:42, 9月前 , 13F
個人覺得正時不是重點，而是網卡成為主時鐘取代了主機版載
07/10 23:42, 13F
→
07/10 23:42, 9月前 , 14F
的爛鐘，從而減少飄移
07/10 23:42, 14F
AoIP 或是 SyncE 需要網卡的 hardware timestamp（附著在每個 packet）去 recover 時鐘資訊，把封包放到最正確時間的點去處理。 我的 case 只是因為網卡夠格當 PTP 主時鐘，因此借用 PHC 直接對系統正時。 若是其他 case 倒是有獨立的 PTP 主時鐘，同樣是用網路方式對全域對時。
→
07/10 23:50, 9月前 , 15F
要網路卡的clock jitter低，建議找10G以上的規格，但是溫飄
07/10 23:50, 15F
→
07/10 23:51, 9月前 , 16F
(單位PPM)跟jitter (單位ns/ps/fs)是兩回事，不同規格
07/10 23:51, 16F
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 00:25:29
推
07/11 01:19, 9月前 , 17F
同意Oswyn講的，音訊重播這塊，絕對時間的長期準確性
07/11 01:19, 17F
→
07/11 01:19, 9月前 , 18F
不很重要，反而是時鐘訊號短期內的穩定性，或者轉化後
07/11 01:19, 18F
短時間 jitter 和長時間穩定都很重要。
→
07/11 01:19, 9月前 , 19F
的所謂相位噪訊，才是關鍵。這跟是不是AOIP無關，概念
07/11 01:19, 19F
→
07/11 01:19, 9月前 , 20F
上類似你音訊是在某時某分某秒完美準確時間開始播放還
07/11 01:19, 20F
→
07/11 01:19, 9月前 , 21F
是在誤差0.0001秒後播放，對聆聽者來說無妨，關鍵還是
07/11 01:19, 21F
即時系統，例如一台機器訊源、一台機器DSP、一台機器分配聲道，三台機器時間 都不一樣又會有什麼情況？其中一台總是慢 100ms、其中一台總是在 +-50ms 之間跳動， 這會無妨嗎？
→
07/11 01:19, 9月前 , 22F
你最終硬體參考的時鐘訊號本身的穩定度能讓每個封包作
07/11 01:19, 22F
→
07/11 01:19, 9月前 , 23F
動的時間間隔夠精準，也就是我說的短期穩定性。這部分
07/11 01:19, 23F
→
07/11 01:19, 9月前 , 24F
考慮網路封包本身延遲的晃動，對時機制反而變成一種干
07/11 01:19, 24F
網路封包本身有快有慢，解決方法是在封包離開網路介面甚至離開交換器（有些交換器 是time-sensitive）時打上timestamp，讓處理端能把封包正確時序恢復。
→
07/11 01:19, 9月前 , 25F
擾，以上是我個人看法。
07/11 01:19, 25F
推
07/11 01:25, 9月前 , 26F
順便問一下Oswyn，關閉Hpet之後，一般系統時鐘應該是
07/11 01:25, 26F
→
07/11 01:25, 9月前 , 27F
直接吃CPU的TSC吧？ 那這樣精確度其實也很高了。
07/11 01:25, 27F
CPU 跑起來時鐘才最不穩定吧？
推
07/11 01:34, 9月前 , 28F
07/11 01:34, 28F
→
07/11 01:34, 9月前 , 29F
以上連結是windows對時工具,安裝後把server設定一下
07/11 01:34, 29F
還有 89 則推文
還有 13 段內文
→
07/11 14:55, 9月前 , 119F
是關鍵。
07/11 14:55, 119F
推
07/11 14:58, 9月前 , 120F
我前面說法有點問題world clock做同步其實有用，算是d
07/11 14:58, 120F
→
07/11 14:58, 9月前 , 121F
ejitter一種手段，沒用的是拿原子鐘做world clock，那
07/11 14:58, 121F
→
07/11 14:58, 9月前 , 122F
種東西相噪根本比不上高檔的ocxo，高精度不等於低相噪
07/11 14:58, 122F
→
07/11 14:59, 9月前 , 123F
現在大家常用USB DAC大部分是非同步模式，那其實搞定D
07/11 14:59, 123F
→
07/11 14:59, 9月前 , 124F
AC上的時鐘就好，系統本身不重要
07/11 14:59, 124F
推
07/11 15:53, 9月前 , 125F
時鐘跟振蕩器是不同的東西 不是說無關啊 振蕩器可以是提供
07/11 15:53, 125F
→
07/11 15:53, 9月前 , 126F
每秒的時間長度 但要決定時間幾點幾分 就是要跟標準時區對
07/11 15:53, 126F
→
07/11 15:53, 9月前 , 127F
時 這樣起點才是對的 但是看樓上回了一串 我還真的看不懂
07/11 15:53, 127F
→
07/11 15:56, 9月前 , 128F
如果Roon的協定就是會用到電腦的時鐘 那大家一起跟中原標準
07/11 15:56, 128F
→
07/11 15:56, 9月前 , 129F
時間對時 這樣沒毛病啊 USB DAC是非對稱運作 所以roon endp
07/11 15:56, 129F
→
07/11 15:56, 9月前 , 130F
oint對時 全部數位訊號到了DAC 就是用內建的晶振來做時間
07/11 15:56, 130F
→
07/11 15:56, 9月前 , 131F
刻度的來源 我是想不出來哪邊有問題
07/11 15:56, 131F
我前面回 Oswyn 大的截圖，裡面有官方的說法。 Roon 的 RAAT 確是用系統時鐘在調節音訊的發送。
→
07/11 16:02, 9月前 , 132F
這個"大家"就很麻煩了
07/11 16:02, 132F
→
07/11 16:34, 9月前 , 133F
USB DAC不是這樣運作的…
07/11 16:34, 133F
推
07/11 16:35, 9月前 , 134F
OOYA
07/11 16:35, 134F
推
07/11 16:41, 9月前 , 135F
振盪器ticks決定時間總長度。拜託不要再執著了好嗎
07/11 16:41, 135F
→
07/11 16:41, 9月前 , 136F
爛錶無論你怎麼事後校正還是爛，不會改變它爛的事實
07/11 16:41, 136F
→
07/11 16:42, 9月前 , 137F
不然一堆溫補晶振是做心酸的喔？跟中原標準時間校正啊
07/11 16:42, 137F
→
07/11 16:42, 9月前 , 138F
反正只要有校正就對了，就是這麼簡單齁(？
07/11 16:42, 138F
推
07/11 16:43, 9月前 , 139F
壞掉的Clock總是會準2次（X
07/11 16:43, 139F
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 16:51:58
推
07/11 17:04, 9月前 , 140F
我比較好奇大家對串流這麼多意見這麼多花招 為甚麼還要玩
07/11 17:04, 140F
→
07/11 17:04, 9月前 , 141F
串流…
07/11 17:04, 141F
推
07/11 17:10, 9月前 , 142F
自己找事情做的概念吧
07/11 17:10, 142F
※ 編輯: elguapo (114.137.234.232 臺灣), 07/11/2023 17:56:27
→
07/11 18:30, 9月前 , 143F
那怎麼又不講OCXO的飄移跟壽命呢 如果真的這麼好 那幹嘛有
07/11 18:30, 143F
→
07/11 18:30, 9月前 , 144F
些地方需要用可以校正的VCXO 再說本文是說Roon的發送信號系
07/11 18:30, 144F
→
07/11 18:30, 9月前 , 145F
統時間 普通電腦沒有人在OCXO
07/11 18:30, 145F
→
07/11 18:56, 9月前 , 146F
老話一句 數位比黑膠還難搞
07/11 18:56, 146F
推
07/11 19:00, 9月前 , 147F
可是數位比較方便阿
07/11 19:00, 147F
→
07/11 19:06, 9月前 , 148F
所以我也是大部分聽 youtube 笑死
07/11 19:06, 148F
推
07/11 19:20, 9月前 , 149F
都好阿
07/11 19:20, 149F
推
07/11 20:12, 9月前 , 150F
數位太方便,所以我聽串流,幾十萬曲目隨選多爽
07/11 20:12, 150F
→
07/11 20:13, 9月前 , 151F
目前NB走usb到DDC,轉成同軸到DAC,所以我只要搞定DDC時鐘
07/11 20:13, 151F
→
07/11 20:13, 9月前 , 152F
即可,於是我把DDC外掛10M時鐘,有沒有用?有,但效益不大.
07/11 20:13, 152F
推
07/11 20:14, 9月前 , 153F
擲筊
07/11 20:14, 153F
→
07/12 11:51, 9月前 , 154F
玩了才知道問題在那裡啊。用看的那來的意見…
07/12 11:51, 154F
推
07/12 12:31, 9月前 , 155F
用看的是趨勢 例如：鋼琴
07/12 12:31, 155F
‣ 更多 elguapo 的文章
文章代碼(AID): #1ah0CQM5 (Audiophile)
討論串 (同標題文章)
完整討論串 (本文為第 1 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 elguapo 的文章
文章代碼(AID): #1ah0CQM5 (Audiophile)