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

: 推 elguapo: 感謝解說。但我的point真的不是DAC的design問題。場景：M 07/13 18:51: → elguapo: ac A 用 Dante 連 Mac B，Mac B 用 internal looping 將 07/13 18:51: → elguapo: 音訊轉給 USB DAC。Dante 和 internal looping 是虛擬介 07/13 18:51: → elguapo: 面。請問音訊資料傳遞時，max A -> Mac B 傳 Dante 時誰 07/13 18:51: → elguapo: 是主鐘？到了 Mac B，Dante 借 internal looping 到 USB 07/13 18:51: → elguapo: 更正: Mac A 07/13 18:53
就我所知，Vitual interfac （自己）沒有音頻時鐘

Vitual interface 可以不需要依存音頻時鐘，因為處理的只是數據流

在這我又要截一大段 Roon 討論串中的對話救援

※

DAC 只能從其本地緩衝區中提取數據，因此它不關心上游的連接。核心只能將數據放入其本地緩衝區，因為它不關心下游的連接。

RAAT 管理兩者之間的數據傳輸，為了確保所有位元能夠完整地從核心傳送到DAC，它使用網絡本身提供的較低層級功能來確保數據的完整性。如果丟失一個數據包，將發送一個新的數據包並按正確順序放入緩衝區。如果數據包損壞，也是同樣的處理方式。在大多數情況下，緩衝區足夠大，以使這個錯誤修復過程能夠在DAC耗盡數據或核心填滿其緩衝區之前進行。

請記住，我在這裡非常謹慎地使用「數據」這個詞，因為這是音樂此時的形式。它是正在播放的文件的位元串流。這是一個異步過程，對DAC的模擬輸出沒有影響。RAAT（以及網絡堆棧）在核心和終端之間促成了一個非常互動的對話。它們確保文件（不超過緩衝區的大小）從核心複製到終端。

……

這是一個異步過程。根據定義，傳輸過程的時序（時鐘同步）與解碼過程完全獨立。緩衝區的填充和清空速率會變化，但只要DAC的緩衝區中有足夠的數據，播放將會持續可靠進行。

這裡的關鍵是區分數據和信號的區別。正在播放的文件在其位元以實時方式通過DAC進行轉換之前，不會變成信號。在它們從DAC（或終端）的本地緩衝區中提取之前，這些位元與用於文檔、圖像甚至本帖中的位元沒有區別。

我理解發燒友不斷嘗試「改進」事物的渴望，這種行為實際上是這個愛好的基礎。在過去，當大多數概念與某些物理事物相關並且變化不僅容易展示，而且還可以通過一些邏輯解釋來支持時，這種改進更容易實現。然而，數字世界並非如此，因為其中許多概念與直覺相悖，解釋也更加複雜。

※

雖然 Vitual interfac 跟 Roon RAAT 有些差異，但本質上是相同的

當 Vitual I/F 的輸出入是同 sample rate 時，Vitual I/F 的做用只是傳遞數據
音頻數據應該被直接 pass through

當輸出輸入是不同 sample rate 時，會需要 SRC，但有兩種選擇

●其一是 SRC 採樣率鎖死，如 44100 Hz 轉 96000 Hz 或等倍的 Oversampling
前端如果是 foobar 之類的 player、不會有時鐘問題，就單純的送資料填 buffer

但輸入與輸出端若有實體時鐘差異會出現 Drift
我們的默認實現使用一種稱為“填充”和“刪除”樣本的技術
基本上是插入或刪除單個樣本。
粗暴有效的解法，有可能出現爆裂聲:D

●另一種就是用 Async SRC、也就是 Drift Correction，但 ASRC 開銷大
Drift Correction 的過程一般 Vitual interfac 也是沒時鐘
因為前後端的進出的樣本數差異，是前後端硬體的時鐘差異造成的
視其中一方為主就解決了，依方向選好主角、另一個配合主角

至少我沒看過有實踐把系統主時鐘拿進來湊一腳，讓系統主時鐘當主角的狀況
但我猜這也是 e大您的理想

※

我上一篇推文中就有提過

Mac 的 Drift Correction 我上面貼的那篇也有提到
彌補的也只是 Audio device 間的 Audio clock 差異
跟 System clock 無關

就像這頁裏的第一個圖
https://support.apple.com/en-us/HT202000

Clock Source 能選系統時鐘嗎？只有 Audio device 能選不是嗎

從 e大當時的回答我就知道在段您想歪了

--
人間五十年、化天のうちを比ぶれば、夢幻の如くなり
^,,,^ 一度生を享け、滅せぬもののあるべきか
(ミ‵ω′)\m/

--

AV-Audio ASIO bridge 這個就是不支援 Drift Correction 的 Vitual interfac 會碰到的問題 當然文件中的例子是是 48000 vs 44093 Hz 但這也展示了實體時鐘差異引起的狀況

因雙方時鐘差異 src端產生 48001 Hz 的資料流、dst端消耗速率為 47999 Hz 要嗎不理它，每秒有兩個樣本最終會被擠掉 不想插入刪除就要校正，src 的 48001 Hz 配合 dst ASRC 成 47999 Hz 如果用超準系統時間，把 src 的 48001 Hz ASRC 成中原標準 48000 Hz 但現實如 Roon 所說的你管不到下游，所以 dst端的消耗速率還是 47999 Hz 把系統生出來的 new 標準 48000 Hz 資料往 dst 送 dst 每秒還是要丟掉一個樣本，除非 dst 上面有自己的 ASRC 再校正一次 但如果 dst 本來就有 Drift Correction，中間多做一次變校兩次有合理嗎 所以我沒看過有人或產品，在傳輸途中這樣做

我又想到另一個不錯的解說 今天我們播放，能從訊源 bit perfect 到 DAC 表示音頻數據在傳輸途中沒有受到任何改變 能 bit perfect 表示沒有發生過任何 DSP、數位音量、DDC 也沒有發生傳輸錯誤、沒發生 Drift、也沒有被 Correction 過 原因為何？ 沒有 Drift 是因為路徑上只有一個音頻時鐘，也就是 DAC's 左手只是輔助，中間都只是數據傳輸

還在不穩定？ 1ms 長的 buffer 經不起 幾百ns 的波動？ 我都覺得 e大您是不是搞不清楚單位了 我想、AoIP 就算每 node 都在 Drift Correction 也是因為 Drift Correction 的點是各 node 的終端 而不會是在傳輸的節點上 Drift Correction 傳輸應該是 passthrough 的，一直在傳輸過程中橋 payload data 這種操作從沒見過 另外、 e大您可以想想 AES67 在跨網域、跨國際運用時 中間的所有 ISP 網通設備時鐘精度會是 10ns 級或是 >100ns AES67 為什麼能正常工作？ 網通設備的主時鐘，是每台機器上自己的時鐘

No，這些設備都是異步它們不關心其它人的時間是幾點 合於規範就好，一如 Roon 所說 AES67 是 layer 3 的擴充 就像 e大PO的圖

上面明示了 Media clock GM 是為了媒體同步而存在的參考時鐘 回到 Roon討論串中，兩種 clock 您必需分清楚各 clock 在不同場合、位置的不同需求與功能 這個 Media clock 明顯不是為了 Physical layer 而生出來的東西 而是為了更後端的應用，媒體同步所打上的時戳 這東西應該是包在封包內的同步「資料」 而非 Physical 運作中會用到的東西

就像 e大您一直在強調，問道什麼場合誰誰誰是主時鐘？ 但裏面有一堆人其實跟本不在一起工作

您看這張圖，RTP 在 Layer 5 一般的網通設備根本不認得 Layer 5 裏的東西是什麼 就只是單純的 payload data 你看一般 Multilayer switch 最多也只到 L3 or L4 你買台能認得 Layer 5 or up 的設備 這根本會是台如視訊這類專門用途的東西 我想說的是，他們在不同「Layer」，不要一直糾結根本在不同層的時鐘 這回樣又能回到 Roon 串中所言及的

Media clock: The clock used by senders to sample and receivers

. The media clock for audio streams reads in units of samples. 一如我上面所述，Media clock 是為了 playback 對齊（同步）用的 不要把這個 timestamp 拉到傳輸過程 因為以封包為基礎的網路傳輸過程，沒有同步這回事

此同步非彼同步，就跟此時鐘非彼時鐘一樣 Internet IP 網路沒有保證先發先至，在極端狀況下後發的封包是有可能先至的

因為這個同步是應用同步，而非傳輸同步 AES67 很明顯是為了應用同步

所以 e大您就是卡在這個點走不出來

S/PDIF 或 Dante-enabled 但絕大多數的用戶都是本機輸出，少部分有 local 串流 like Roon RAAT 追求傳輸過程精確同步實在沒多少意義 而且嚴格說 AES67 追求的是短延遲、媒體同步 而這並不需要超精準時鐘

但 e大您上面說 AoIP 是每個 node 都在做 drift correction。司空見慣

‧ Grade 2 DARS (AES11 clause 5.2) ±10 ppm ‧ Grade 1 DARS optional ±1 ppm ‧ ±100 ppm adjustability, ±250 ppm recommended 1ppm 約 0.09 sec/day 約每秒 1041.667ns 的徧差 不知道有沒有算錯但好像不用壓到 10ns 的精度 所以壓到超過規範意義在哪？ 僅合規範會無法正常工作、會影響音質嗎？ AES67 中我也沒看到有什麼提升音質的描述 我只能說 e大您的立論從一開始就沒有任何基礎，純粹是個人想像

我否定的是無根據的不科學假設

我個人認為，數位音頻在兩個點時間關鍵 採樣的 ADC，與重建的 DAC 當聲音被轉成離散的 PCM ，就沒有時鐘的問題，因為這是單純的數據 這也是 Roon 在討論串中想表達的 也所以 Vitual interfac 只有定 Sampling rate 這裏的 Sampling rate 只是規格 就像 wav、fac、mp3 檔裏也會定義檔案的 Sampling rate 這是告訴使用這個檔案的人（程式），檔案裏的數據是什麼 Sampling rate 在沒有 DA 介入的狀態，數據就只是數據 除非有意的 DSP，數據不應在傳輸的過程中發生意圖外的變化 而 Drift Correction 不太可能會是在傳輸過程中需要進行的 這就跟 Dithering、Noise shaping 一樣，理想上應該在最後一段進行

PCM 是以固定間隔（時間）擷取、量化的離散數據 只還數據還是數據，這個間隔就只是常數，而非實際時間 如果數據與數據間需要精確的時間，別說單純傳輸音頻數據 Digital audio 還能被 DAW 輕鬆數位後製嗎 應該很難吧，所有做出來的音樂應該都跳痛不已 這也是為什麼我會認為一開始 e大就在假設上完全想歪了

一般有截斷 bit depth 才需要 但如果有對 16-bit audio data 進行 DSP，因為 DSP chain 工作在浮點 DSP 後的數據會是浮點，如果輸出為浮點或 24-bit 做不做抖動是看選擇 但如果輸出還是只能 16-bit 一般是建議要抖動，而噪聲整形就看選擇了

所以沒需求的話不要動數據 bit perfect 給 DAC 因為音源在母帶處理後一般都包好了抖動與噪聲整形 能不破壞原始數據最好 也所以數位音量最好不要在中間做，如果要用最好用 DAC 上的數位音量

沒辦法，因為 Windows Audio 堆棧的本質是混音器

除了某些腦子開洞的 Plugin 會用整數做 DSP（這種的通常會自傲的聲明 一般 Plugin 都是用浮點處理數據，32-bit float 較常見、64-bit 較少見 另一個問題是你掛 VST 的 Host 是用什麼數據格式在處理 DSP 跟上面一樣 32-bit float 較常見、64-bit 較少見 但一般而言 DSP 完都會是浮點數

這個 VST 可以顯示目前數據流的位深 在 SIR3 的前後各掛一個，就可以看到變化