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

看板Audiophile (電腦喇叭音響系統)作者Oswyn (Oswyn)時間1年前 (2023/07/13 20:20)推噓10(10推 0噓 95→)

留言105則, 7人參與討論串4/5 (看更多)

: 推 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

推

djboy

07/13 20:28, 1年前 , 1^F

07/13 20:28, 1^F

推

greg7575

07/13 20:30, 1年前 , 2^F

07/13 20:30, 2^F

https://i.imgur.com/DhyCdjj.jpg

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 左手只是輔助，中間都只是數據傳輸

→