作者
標題 [心得] 運用 Chrony 對時工具提升音訊品質
時間 Mon Jul 10 21:09:44 2023
標題 [心得] 運用 Chrony 對時工具提升音訊品質
時間 Mon Jul 10 21:09:44 2023
「紊亂的電腦系統時鐘，經過對時調節（realtime clock）到接近 AES11 Grade 2
的精度，進而增進電腦音訊品質。」
自從開始使用 Ravenna/AES67 AoIP 之後，對於時間的準確度也越來越要求；不久
前收了一張具備 GPS 接收器的 Intel E810-XXVDA4TGG1 網路卡，作為我的 AES67
的主時鐘，並將開箱文貼到 audiophilestyle 網站：
前收了一張具備 GPS 接收器的 Intel E810-XXVDA4TGG1 網路卡，作為我的 AES67
的主時鐘，並將開箱文貼到 audiophilestyle 網站：
https://tinyurl.com/3p8ccjv2
Intel E810-XXVDA4TGG1 -- an alternative choice for AES67 GPS Grandmaster Clock - Networking, Networked Audio, and Streaming - Audiophile Style
![[圖]]()
![[圖]]()
![[圖]]()
Previously I configured two Intel 82574L and ran ptp4l as boundary clock for my Ravenna network: After such post I kept searching possible solutions f ...
![[圖]](https://i4.disp.cc/t/s2/audiophilestyle.com/1aa38de8c5d521d30f9199aff5d1aa1c.jpg)
![[圖]](https://i4.disp.cc/t/s2/audiophilestyle.com/65125d0fff3822a495f7aa70b26b20d7.jpg)
![[圖]](https://i4.disp.cc/t/s2/audiophilestyle.com/5b7ca89425c4413fabb74e1826d41f91.jpg)
本來想在 ptt 補充一下中文的部分，但後來發現有更值得討論的內容，遂決定先來
寫關於電腦作業系統時鐘的校對問題。
以 48000Hz 取樣率的音樂來說好了，相信很多燒友應該會認為是 48000Hz 的「
載波」在傳遞音訊。若有讀過 AES3 以及 AES67 的規範，其實音訊的傳遞是「每秒
傳送 48000 個取樣值」，若切更細一點，以 AES67 來說，數位音訊是每 1ms 傳送
48 個取樣值到目的地。
傳送 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
經過這樣的對時，HQPe 主機的時間精度可以達 +-10ns 範圍！個人發現 HQPe PCM
的升頻變好聽很多，毛躁感降低不少，慢慢的也懶得升頻 DSD 了。
https://imgur.com/E1aTEZm.jpg
![[圖]](https://i.imgur.com/E1aTEZmh.jpg)
後來再進一步將我的 Fitlet3 NAA 用光纖掛上 E810 的其中一個 SFP28 port，
用同個 PTP hardware clock，傳送 layer 2 的 802.1AS gPTP 的對時資料給
Fitlet3。
https://imgur.com/etMHOn7.jpg
![[圖]](https://i.imgur.com/etMHOn7h.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
![[圖]](https://i.imgur.com/JXzcrkRh.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
![[圖]](https://i.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
![[圖]](https://i.imgur.com/gRrAVjFh.jpg)
主要看橘色的線，是代表系統時間均值，以截圖來看，我的 MBP13" 經過對時可以
達到並穩定在 AES11 Grade 2 +-10ppm 的要求了。
由於我對 Windows 作業系統工具不是很熟，增加對時頻率的方法可能要請版上高人
補完了... Orz
希望這個 Linux or macOS 系統設定的變動能為「以電腦為主要播放器材」的版友
帶來助益 :-)
「對時，是為了要有：一致的一秒長度、一致的一秒起點以及一致的曆日」。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.96.60 (臺灣)
※ 作者: elguapo 2023-07-10 21:09:44
※ 文章代碼(AID): #1ah0CQM5 (Audiophile)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1688994586.A.585.html
※ 同主題文章:
[心得] 運用 Chrony 對時工具提升音訊品質
07-10 21:09
07-11 20:49
07-13 16:33
07-13 20:20
07-15 00:01
※ elguapo:轉錄至看板 Headphone 07/10 21:15
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:11:10
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:18:41
IME 在 free clock 狀態是無法滿足條件的。
正時後就有機會能符合這些要求。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:52:51
，令時鐘維持在理想的誤差範圍內。
時鐘資訊，把封包放到最正確時間的點去處理。
我的 case 只是因為網卡夠格當 PTP 主時鐘，因此借用 PHC 直接對系統正時。
若是其他 case 倒是有獨立的 PTP 主時鐘，同樣是用網路方式對全域對時。
都不一樣又會有什麼情況？其中一台總是慢 100ms、其中一台總是在 +-50ms 之間跳動，
這會無妨嗎？
是time-sensitive）時打上timestamp，讓處理端能把封包正確時序恢復。
恢復 free clock 再聽，就知道有沒有不一樣了。
先聽正時原因是對時對到正時並穩定需要一些時間，而破壞正時卻非常容易。
的 Ravenna driver 都只是 software slave mode，不會用到網卡的 PHC，故無法借
AES67 的時鐘資訊對電腦系統對時，電腦在這邊仍是 free clock state。
因此仍是需要另一個對時方式去將電腦正時。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 07:47:47
會買一張來用。
我貼這篇文也是很怕「晶振」和「時鐘」被混淆，尤其兩個英文都是 clock...
晶振，是數位電子的心臟，也可以作為一秒的參考來源（例如 10MHz ref signal）。
時鐘，是提供年月日時分秒的東西，時鐘的一秒長度定義，可以來自原子震盪頻率、
也可以來自晶振提供的 10MHz ref signal、也可以用來自衛星的 1PPS，甚或是電腦
自己用 looping 來算時間。
晶振，不會提供時間的起點，更不會去算閏秒。
時鐘，是時間起點的依據，UTC 時間也會根據 TAI 原子鐘算閏秒。
電腦的排程，例如每天早上六點叫起床，是依據「系統時鐘」來做，而不是晶振。
同樣的，電腦要每秒送出 48000 個數據，也是依據電腦自己的系統時鐘來做。
對於 DAC 的時鐘和電腦系統時鐘到底有沒有關係？我個人認為有關。
一般 USB DAC 會藉由 USB 控制晶片回傳 DAC 時鐘頻率給電腦，若電腦和 DAC 時鐘
有些落差，那麼電腦會採取 resampling 方式去符合 DAC 的頻率再把資料發送出去。
這點可從 macOS 的 Audio MIDI Setup 得證。
而這個 resampling 的過程，仍是吃電腦的系統時鐘來做；若電腦的系統時鐘不精確，
該如何保證 resampling 的品質？
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 12:17:09
![[圖]]()
我們稱的 48000Hz 音訊，在 AES67 的定義，指的是「每秒 48000 個 samples」，
是離散的資料。換算每 1ms 送 48 個 samples，或是每 0.125ms 送 6 個 samples。
這裡無涉晶振，只和系統時間準確度有關（同時包含一秒的長度和一秒的起點）。
音訊均為數位且為即時系統，請問這樣的場景如何 close loop?
會歪很嚴重。
說個小故事：
我曾經買了一套軟體，授權是線上授權由中央伺服器控管。
結果使用三個月後我發現我買的軟體竟然授權失效@@，寫信給原作也找不出原因（
換了好幾個 license 也無法啟動）。
後來原作寫信給授權管理中心，他們只問我的電腦有沒有上網，我說我的電腦 24h
都在網路上怎麼可能沒連網（笑）。
結果授權中心也是為了我的問題花了好幾天功夫，才找到線索——上次授權查詢的
時間戳記和授權伺服器的時間沒對上，造成授權失效。
後來我才發現原來我的電腦時鐘已經和隨便一台 NTP 差了大概 5min 吧。
三個月歪掉 5min... 後來我都乖乖的沒事就檢查一下 NTP 服務是否正常，電腦對時
有沒有對正，避免同樣的糗事發生。
![[圖]]()
請參考這段描述
https://imgur.com/rna42dF.jpg
![[圖]]()
System clock 確實有在 loop 內
https://tinyurl.com/39w2b2we
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:31:59
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:43:30
Roon 的 RAAT 確是用系統時鐘在調節音訊的發送。
--
推 : 感謝造福眾小資 已設置且感受明顯1F 07/10 21:47
推 : 雖然看不懂還是推2F 07/10 21:51
推 : 謝分享 順便問apple music 在mac還是不會自動抓分辨率嗎(取樣率
補推3F 07/10 21:52
目前還是不行... sorry :-(補推3F 07/10 21:52
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:11:10
推 : 這樣效果有比外接主時鐘還好嗎？6F 07/10 22:10
好奇問，請問市售哪台電腦可以接鐘？抱歉我可能有盲點...※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:18:41
推 : 只會win10手動對時完快速聽歌7F 07/10 22:30
→ : 對時完 不還是照自己的時鐘跑嗎:D8F 07/10 22:46
AES11 有規範，音訊節點與節點的銜接誤差要小於 +-50ppm。基本上電腦的 CLOCK_REALTIME 在 free clock 狀態是無法滿足條件的。
正時後就有機會能符合這些要求。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/10/2023 22:52:51
推 : 如果有時鐘 感覺自己做個NTP伺服器 給所有設備9F 07/10 23:11
推 : 推 但我疑惑的點是 對時以後 晶振的品質還是一樣沒有改變啊?10F 07/10 23:27
電腦主機板的時鐘品質並不理想，且不考慮 holdover 性能，因此需要將對時的頻率提高，令時鐘維持在理想的誤差範圍內。
→ : 但為了以後演場會更好搶票 我還是做了正時XD11F 07/10 23:27
推 : 推，感覺很有趣，晚點來試試12F 07/10 23:39
→ : 個人覺得正時不是重點，而是網卡成為主時鐘取代了主機版載的爛鐘，從而減少飄移13F 07/10 23:42
AoIP 或是 SyncE 需要網卡的 hardware timestamp（附著在每個 packet）去 recover時鐘資訊，把封包放到最正確時間的點去處理。
我的 case 只是因為網卡夠格當 PTP 主時鐘，因此借用 PHC 直接對系統正時。
若是其他 case 倒是有獨立的 PTP 主時鐘，同樣是用網路方式對全域對時。
→ : 要網路卡的clock jitter低，建議找10G以上的規格，但是溫飄(單位PPM)跟jitter (單位ns/ps/fs)是兩回事，不同規格15F 07/10 23:50
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 00:25:29推 : 同意Oswyn講的，音訊重播這塊，絕對時間的長期準確性不很重要，反而是時鐘訊號短期內的穩定性，或者轉化後17F 07/11 01:19
短時間 jitter 和長時間穩定都很重要。→ : 的所謂相位噪訊，才是關鍵。這跟是不是AOIP無關，概念上類似你音訊是在某時某分某秒完美準確時間開始播放還是在誤差0.0001秒後播放，對聆聽者來說無妨，關鍵還是19F 07/11 01:19
即時系統，例如一台機器訊源、一台機器DSP、一台機器分配聲道，三台機器時間都不一樣又會有什麼情況？其中一台總是慢 100ms、其中一台總是在 +-50ms 之間跳動，
這會無妨嗎？
→ : 你最終硬體參考的時鐘訊號本身的穩定度能讓每個封包作動的時間間隔夠精準，也就是我說的短期穩定性。這部分考慮網路封包本身延遲的晃動，對時機制反而變成一種干22F 07/11 01:19
網路封包本身有快有慢，解決方法是在封包離開網路介面甚至離開交換器（有些交換器是time-sensitive）時打上timestamp，讓處理端能把封包正確時序恢復。
→ : 擾，以上是我個人看法。
順便問一下Oswyn，關閉Hpet之後，一般系統時鐘應該是直接吃CPU的TSC吧？ 那這樣精確度其實也很高了。25F 07/11 01:19
CPU 跑起來時鐘才最不穩定吧？順便問一下Oswyn，關閉Hpet之後，一般系統時鐘應該是直接吃CPU的TSC吧？ 那這樣精確度其實也很高了。25F 07/11 01:19
推 : https://www.timesynctool.com/
以上連結是windows對時工具,安裝後把server設定一下
然後連線到https://time.is 看看對時效果28F 07/11 01:34
以上連結是windows對時工具,安裝後把server設定一下
然後連線到https://time.is 看看對時效果28F 07/11 01:34
![[圖]](https://time.is//img/shareable/time_is_110011.png)
→ : 但說真的,我替DDC加上個10M鐘,對音色的提升程度很小
所以頻繁的讓PC與NTP server對時,我可能聽不出來差異吧31F 07/11 01:41
要比較電腦對時有無差異其實蠻簡單的，先聽正時的一陣子，然後電腦重新開機讓電腦所以頻繁的讓PC與NTP server對時,我可能聽不出來差異吧31F 07/11 01:41
恢復 free clock 再聽，就知道有沒有不一樣了。
先聽正時原因是對時對到正時並穩定需要一些時間，而破壞正時卻非常容易。
推 : 一般 clocksource 有這三種，tsc/hpet/acpi 可以都測看看33F 07/11 01:53
→ : 我個人是覺得「時間」跟「計時」是兩件事，就像 TSC 本質是個計數器，一般來說 TSC 是 ns 等級、HPET 是 100ns
但這些計數器還是要以其「頻率」回推才能得出「時間」
時間關鍵應用需要的是頻率穩定、計數就會穩定、間隔才會穩其實就是我在 #1aMUsw3K 這篇裏提到的 Drift 問題34F 07/11 02:07
但這些計數器還是要以其「頻率」回推才能得出「時間」
時間關鍵應用需要的是頻率穩定、計數就會穩定、間隔才會穩其實就是我在 #1aMUsw3K 這篇裏提到的 Drift 問題34F 07/11 02:07
Re: [閒聊] PC訊源雜訊解法 - 看板 Audiophile - 批踢踢實業坊
作者: Oswyn (Oswyn) 會嗶嗶啵啵的症狀我個人粗分三類 訊源本身造成的，像快轉、切歌這些 傳輸過程有問題，像 DPC、Buffer size、Driver、API、S/W、H/W 等出狀況 另外一種是傳輸過程沒問題但還是出問題，也就是 Clock drift 這類看到鬼的 為什麼會有問題，下面這個文件中已經指出來了
作者: Oswyn (Oswyn) 會嗶嗶啵啵的症狀我個人粗分三類 訊源本身造成的，像快轉、切歌這些 傳輸過程有問題，像 DPC、Buffer size、Driver、API、S/W、H/W 等出狀況 另外一種是傳輸過程沒問題但還是出問題，也就是 Clock drift 這類看到鬼的 為什麼會有問題，下面這個文件中已經指出來了
→ : 比方說 這個系統加上一台MERGING+CLOCK做主時鐘 這樣跟現在這個作法有什麼差別嗎？不是很懂39F 07/11 02:16
Merging+Clock 雖說可以當 AES67 網路主時鐘，但電腦接收介面（Mac / Win / Linux）的 Ravenna driver 都只是 software slave mode，不會用到網卡的 PHC，故無法借
AES67 的時鐘資訊對電腦系統對時，電腦在這邊仍是 free clock state。
因此仍是需要另一個對時方式去將電腦正時。
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 07:47:47
推 : LP播放你會在意馬達轉速穩定，還是要變DJ台？
裝一個電波錶，"對時"拉拉扯扯這樣子的感覺嗎？41F 07/11 07:41
對時到正時且穩定需要時間，過程一定會有拉扯，這需要一點耐心。裝一個電波錶，"對時"拉拉扯扯這樣子的感覺嗎？41F 07/11 07:41
→ : 市售電腦可以接鐘的產品，可以參考sotm43F 07/11 07:42
SoTM的主機板我知道有 ref input，但那個並沒有用在系統時鐘上面？若是有的話我會買一張來用。
推 : 每30秒DJ打碟囉！44F 07/11 07:44
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 07:52:30推 : 一致的一秒長度是關鍵沒錯，但十秒一次的對時能改善這件事？ 我意思是能影響振盪器本身的相位噪訊？ 我理解的是對時能通過校準讓對時瞬間的絕對時間對齊，但這能影響振盪器本身的穩定度？ 如果可以的話那確實會有用。45F 07/11 08:53
→ : 其實前面網友都說的很清楚了，“長時間準”對音樂系統跟本一點都不重要，短時間準才是重點，每十分鍾差個一秒跟本感覺不出來的，但拍子忽快忽慢就不行
再者訊號到dac之後，都用dac的鐘了，前面的訊號（電腦）再如何準，意義不大50F 07/11 09:24
再者訊號到dac之後，都用dac的鐘了，前面的訊號（電腦）再如何準，意義不大50F 07/11 09:24
→ : 聽說如果用DDC走II2(hdmi)餵訊號給DAC,時鐘會以DDC（電腦/外接）為準,是真的嗎？55F 07/11 09:58
→ : 回樓上 看dac設計 i2s有clock訊號沒錯 但還是得看dac吃不吃 另外，現在ddc一般都是用非同步usb了，所以應該不會吃電腦的clock57F 07/11 10:02
推 : 通常需要頻繁校時的系統時鐘的品質就不會太好，我自己工作上有對時間要求非常嚴格的系統，通常這種系統上要調一秒都要花數小時甚至一整天去慢慢攤平那一秒，不會頻繁跟Time Server校時
另外音響上LAN串流的東西不適合跟DAC的運作混為一談，有些LAN串流的通訊協定為了多套設備同步資料裡會帶時間資訊，那來源電腦的時間如果偏擺太嚴重是會有影響的，串流機收到LAN串流的東西再整理成同步訊號給DAC是另一回事了60F 07/11 10:13
另外音響上LAN串流的東西不適合跟DAC的運作混為一談，有些LAN串流的通訊協定為了多套設備同步資料裡會帶時間資訊，那來源電腦的時間如果偏擺太嚴重是會有影響的，串流機收到LAN串流的東西再整理成同步訊號給DAC是另一回事了60F 07/11 10:13
推 : XOY 說到重點，確實就是目前的主流結論。
原原PO 這麼的熱血的製作並分享，值得給推m文啊68F 07/11 10:43
原原PO 這麼的熱血的製作並分享，值得給推m文啊68F 07/11 10:43
推 : clock是振盪精度不是中原標準時間70F 07/11 11:07
→ : 非同步不吃電腦clock
然後此clock跟彼clock不一樣吧?
穩定度跟對齊兩者不太一樣吧?71F 07/11 11:10
然後此clock跟彼clock不一樣吧?
穩定度跟對齊兩者不太一樣吧?71F 07/11 11:10
推 : 我覺得"clock"這個字可能某種程度讓人誤解了
不過不可思議的是有人試有明顯改善那試試再說...74F 07/11 11:41
綜觀各位大大的留言：不過不可思議的是有人試有明顯改善那試試再說...74F 07/11 11:41
我貼這篇文也是很怕「晶振」和「時鐘」被混淆，尤其兩個英文都是 clock...
晶振，是數位電子的心臟，也可以作為一秒的參考來源（例如 10MHz ref signal）。
時鐘，是提供年月日時分秒的東西，時鐘的一秒長度定義，可以來自原子震盪頻率、
也可以來自晶振提供的 10MHz ref signal、也可以用來自衛星的 1PPS，甚或是電腦
自己用 looping 來算時間。
晶振，不會提供時間的起點，更不會去算閏秒。
時鐘，是時間起點的依據，UTC 時間也會根據 TAI 原子鐘算閏秒。
電腦的排程，例如每天早上六點叫起床，是依據「系統時鐘」來做，而不是晶振。
同樣的，電腦要每秒送出 48000 個數據，也是依據電腦自己的系統時鐘來做。
對於 DAC 的時鐘和電腦系統時鐘到底有沒有關係？我個人認為有關。
一般 USB DAC 會藉由 USB 控制晶片回傳 DAC 時鐘頻率給電腦，若電腦和 DAC 時鐘
有些落差，那麼電腦會採取 resampling 方式去符合 DAC 的頻率再把資料發送出去。
這點可從 macOS 的 Audio MIDI Setup 得證。
而這個 resampling 的過程，仍是吃電腦的系統時鐘來做；若電腦的系統時鐘不精確，
該如何保證 resampling 的品質？
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 12:17:09
![[圖]](https://i.imgur.com/itPoVWI.jpg)
→ : 看到後面說明就知道你是混淆了…77F 07/11 12:48
我並沒有混淆，而且在本文已經解釋很清楚了。我們稱的 48000Hz 音訊，在 AES67 的定義，指的是「每秒 48000 個 samples」，
是離散的資料。換算每 1ms 送 48 個 samples，或是每 0.125ms 送 6 個 samples。
這裡無涉晶振，只和系統時間準確度有關（同時包含一秒的長度和一秒的起點）。
推 : 資料傳輸的interface通常用的是晶振吧…78F 07/11 12:51
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 13:21:34→ : 所以說 Mac's Audio 設定裏的 clock 都是 I/F not SystemAudio device 是不看 系統時間 的79F 07/11 13:21
推 : 不懂明明很簡單的close loop控制，要用那麼複雜的open loop來解？81F 07/11 13:39
一台電腦為訊源，接一台電腦 DSP，然後輸出給中控，中控再控制 2 台 DAC 多聲道音訊均為數位且為即時系統，請問這樣的場景如何 close loop?
推 : 抱歉。我看本文還不確定是不是真的這樣…只是覺得不可思議那外接時鐘是拿來對時嗎？83F 07/11 13:49
→ : 外接時鐘是為了 同步85F 07/11 13:51
→ : 我是指樓主的情況……不然外接時鐘是為了對時嗎？- -86F 07/11 13:51
推 : 看不太懂@@ 電腦系統比NTP server慢1秒，會如何影響效能？電腦沒對時的話 (斷網)，應該不會影響本機每1秒內的長度啊?還是指電腦沒定期對時的話,本機每1秒內的長度會改變? (跑掉87F 07/11 13:52
電腦的時鐘本身精度不高，加上並沒有 hold-over 設計，所以一旦久未對時，時鐘會歪很嚴重。
說個小故事：
我曾經買了一套軟體，授權是線上授權由中央伺服器控管。
結果使用三個月後我發現我買的軟體竟然授權失效@@，寫信給原作也找不出原因（
換了好幾個 license 也無法啟動）。
後來原作寫信給授權管理中心，他們只問我的電腦有沒有上網，我說我的電腦 24h
都在網路上怎麼可能沒連網（笑）。
結果授權中心也是為了我的問題花了好幾天功夫，才找到線索——上次授權查詢的
時間戳記和授權伺服器的時間沒對上，造成授權失效。
後來我才發現原來我的電腦時鐘已經和隨便一台 NTP 差了大概 5min 吧。
三個月歪掉 5min... 後來我都乖乖的沒事就檢查一下 NTP 服務是否正常，電腦對時
有沒有對正，避免同樣的糗事發生。
→ : a從起點直線走到十米外
b從起點後一米直線走到離起點十一米
a在丟飛鏢時都丟在靶心散佈5cm
b固定丟在右側密集不散開1cm
a以等頻率實時同步投影字母給a2念稿
b稍加整理後以每段方式丟給b2念稿
a這邊以精準的每秒寫一個字 湊出一段句子 丟給b讀稿
結果b不理a照自己的語速去讀稿
b念出來後 a發現b念錯了
a發現b根本不屌他
也無法阻止b90F 07/11 13:56
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:18:38b從起點後一米直線走到離起點十一米
a在丟飛鏢時都丟在靶心散佈5cm
b固定丟在右側密集不散開1cm
a以等頻率實時同步投影字母給a2念稿
b稍加整理後以每段方式丟給b2念稿
a這邊以精準的每秒寫一個字 湊出一段句子 丟給b讀稿
結果b不理a照自己的語速去讀稿
b念出來後 a發現b念錯了
a發現b根本不屌他
也無法阻止b90F 07/11 13:56
→ : https://i.imgur.com/OilLwDf.jpg
據我所知的 Audio device's clock 跟 roon 的解釋一致我猜原PO看到的 Roon 所說以電腦播放是以電腦自己的鐘為準應該指的是電腦上的 Audio device's clock not system's101F 07/11 14:15
據我所知的 Audio device's clock 跟 roon 的解釋一致我猜原PO看到的 Roon 所說以電腦播放是以電腦自己的鐘為準應該指的是電腦上的 Audio device's clock not system's101F 07/11 14:15
![[圖]](https://i.imgur.com/OilLwDf.png)
https://imgur.com/rna42dF.jpg
![[圖]](https://i.imgur.com/rna42dFh.jpg)
https://tinyurl.com/39w2b2we
RAAT and clock ownership - #2 by brian - Roon Software Discussion - Roon Labs Community
![[圖]]()
From the RAAT vs AirPlay thread @Brian stated - I've got a few questions. But they don't relate to AirPlay specifically, hence the new thread. ...
![[圖]](https://roon-community-uploads.s3.amazonaws.com/original/3X/6/1/61b74829d3a9316be3c3afa68d310cb91d7c6bc5.png)
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:43:30
推 : https://reurl.cc/XExV7D 外接時鐘主要是在錄音室之
類，大約有7+以上的器材需要同時運作，所以時間必需要
對齊，錄出來的聲音才會準確。
一般人的設備就3、4台，實在用不太到；而且DAC也是用旁邊的晶振是最好且誤差最小。105F 07/11 14:40
類，大約有7+以上的器材需要同時運作，所以時間必需要
對齊，錄出來的聲音才會準確。
一般人的設備就3、4台，實在用不太到；而且DAC也是用旁邊的晶振是最好且誤差最小。105F 07/11 14:40
Does Your Studio Need A Digital Master Clock?
Can an external clock signal really improve the performance of your digital audio devices? We put seven of the best master clocks through their paces ...
Can an external clock signal really improve the performance of your digital audio devices? We put seven of the best master clocks through their paces ...
推 : low phase noise跟準不準沒什麼關聯，很早以前Lavry就有文章打臉那些拿原子鐘做world clock的根本沒什麼屁用了
現在DAC做時基重整的手段一堆，最高級的就是搞一個low phase noise的OCXO當時鐘110F 07/11 14:43
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 14:50:06現在DAC做時基重整的手段一堆，最高級的就是搞一個low phase noise的OCXO當時鐘110F 07/11 14:43
推 : 其實我也不懂原Po為何一直覺得系統時間跟振盪器無關？ 在free clock下他就是要吃某顆振盪器的訊號啊，也許是CPU的TSC或是板子上的HPET。同步頻率十秒一次能改變這些原有振盪器的穩定度或者說相位噪訊？ 我覺得這才是關鍵。115F 07/11 14:55
推 : 我前面說法有點問題world clock做同步其實有用，算是dejitter一種手段，沒用的是拿原子鐘做world clock，那種東西相噪根本比不上高檔的ocxo，高精度不等於低相噪現在大家常用USB DAC大部分是非同步模式，那其實搞定DAC上的時鐘就好，系統本身不重要120F 07/11 14:58
推 : 時鐘跟振蕩器是不同的東西 不是說無關啊 振蕩器可以是提供每秒的時間長度 但要決定時間幾點幾分 就是要跟標準時區對時 這樣起點才是對的 但是看樓上回了一串 我還真的看不懂如果Roon的協定就是會用到電腦的時鐘 那大家一起跟中原標準時間對時 這樣沒毛病啊 USB DAC是非對稱運作 所以roon endpoint對時 全部數位訊號到了DAC 就是用內建的晶振來做時間刻度的來源 我是想不出來哪邊有問題125F 07/11 15:53
我前面回 Oswyn 大的截圖，裡面有官方的說法。Roon 的 RAAT 確是用系統時鐘在調節音訊的發送。
→ : 這個"大家"就很麻煩了132F 07/11 16:02
→ : USB DAC不是這樣運作的…133F 07/11 16:34
推 : OOYA134F 07/11 16:35
推 : 振盪器ticks決定時間總長度。拜託不要再執著了好嗎
爛錶無論你怎麼事後校正還是爛，不會改變它爛的事實
不然一堆溫補晶振是做心酸的喔？跟中原標準時間校正啊反正只要有校正就對了，就是這麼簡單齁(？135F 07/11 16:41
爛錶無論你怎麼事後校正還是爛，不會改變它爛的事實
不然一堆溫補晶振是做心酸的喔？跟中原標準時間校正啊反正只要有校正就對了，就是這麼簡單齁(？135F 07/11 16:41
推 : 壞掉的Clock總是會準2次（X139F 07/11 16:43
※ 編輯: elguapo (118.163.96.60 臺灣), 07/11/2023 16:51:58推 : 我比較好奇大家對串流這麼多意見這麼多花招 為甚麼還要玩串流…140F 07/11 17:04
推 : 自己找事情做的概念吧142F 07/11 17:10
※ 編輯: elguapo (114.137.234.232 臺灣), 07/11/2023 17:56:27→ : 那怎麼又不講OCXO的飄移跟壽命呢 如果真的這麼好 那幹嘛有些地方需要用可以校正的VCXO 再說本文是說Roon的發送信號系統時間 普通電腦沒有人在OCXO143F 07/11 18:30
→ : 老話一句 數位比黑膠還難搞146F 07/11 18:56
推 : 可是數位比較方便阿147F 07/11 19:00
→ : 所以我也是大部分聽 youtube 笑死148F 07/11 19:06
推 : 都好阿149F 07/11 19:20
推 : 數位太方便,所以我聽串流,幾十萬曲目隨選多爽
目前NB走usb到DDC,轉成同軸到DAC,所以我只要搞定DDC時鐘即可,於是我把DDC外掛10M時鐘,有沒有用?有,但效益不大.150F 07/11 20:12
目前NB走usb到DDC,轉成同軸到DAC,所以我只要搞定DDC時鐘即可,於是我把DDC外掛10M時鐘,有沒有用?有,但效益不大.150F 07/11 20:12
推 : 擲筊153F 07/11 20:14
--
作者 elguapo 的最新發文:
- 153F 40推 1噓
- 前情大致交代一下： 今年初才加入 Nintendo Switch 的大家庭，很多遊戲沒玩過（含異度神劍系列）； 聽口碑異度神劍第一代很值得玩，趁六月上市首波從港任入手電子版開始，發瘋似的 一路玩到加碼 …31F 20推
![]()
完整標題：‘It is not COVID-19’: Indonesian health official mixes up disease and virus 發稿單位：The Jakarta Po …128F 44推 2噓- 看板 Gossiping作者 elguapo (HPHT Synthesized)標題 Re: 華航勞資糾紛的下文？（微爆掛）時間 Fri Mar 6 11:38:31 2015 （恕刪） 首先 …82F 75推 3噓
點此顯示更多發文記錄