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/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.136.195.49 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689250827.A.387.html