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

看板Audiophile (電腦喇叭音響系統)作者Oswyn (Oswyn)時間9月前 (2023/07/11 20:49)推噓103(104推 1噓 208→)

留言313則, 26人參與討論串2/5 (看更多)

RAAT and clock ownership https://community.roonlabs.com/t/raat-and-clock-ownership/6915 這是個很長的討論串，但內容應該不太複雜把重點放在兩位 Roon 員工對使用者提問的回答 brian | Brian Luczkiewicz | Roon Labs Founder AMP | Andrew P | Roon Labs 在此為了方便閱讀用 Google 英翻中，挑重點不然篇幅太長，有疑慮請參照原文其實對本話題有興趣的朋友，都應該要去看完整原文只有完整從頭看到尾，才能真正理解 Roon 在講什麼在此我只能簡單的拉出一些關鍵段落但其實大部分的內容都很重要，且有前後連續性（刪很多還是很多 ※ 關於音頻時鐘的大多數討論都集中在時鐘質量，而不是時鐘一致性。本次討論是關於後者的。“抖動”這個詞不屬於本次討論的範圍。RAAT 對該領域沒有影響。它異步移動音頻緩衝區，就像 USB 一樣。它不參與生成驅動 DAC 的時鐘信號。在最好的系統架構中，您將擁有一個時鐘：DAC 附近的高質量時鐘。該時鐘負責準確地輸出數據（低抖動等），並負責設置流經系統的數據緩衝的速度。 ※ RAAT 流媒體永遠不會添加時鐘差異源。不要將流媒體視為設備的擴展，而應將 RAAT 視為 Roon 的擴展，讓 Roon 出現在流媒體上。／在 RAAT 的架構中，在單區域播放期間，RAAT 或 Roon 中永遠不會發生推送。（多區域播放時，其中一個區域“拉”，Roon“推”到其餘區域，利用從第一個區域恢復的時鐘來控制速率。這是不可避免的，因為沒有辦法強制多個區域獨立時鐘源一致，因此在這種情況下，我們需要使用如上所述的漂移補償技術。） ※ 因為 Roon 要支援「網路多區域播放」，因為有多個設備所以數據傳輸管理才更複雜Ｑ：因為聽起來我們不需要過度擔心除 DAC 之外的任何時鐘的質量，因為 RAAT 正在為我們解決這個問題。這是真的嗎？是的，這是正確的。 ※ ↑如果覺得太多字，看完這句回答就可以回上一頁了對於多區域，我們在拉動模式下運行已被選為主時鐘的區域，並推送到其他區域，這些區域被迫在內部補償漂移。實際的實現是稍微間接的。核心知道將數據包發送到端點的速度不是因為明確的數據請求，而是因為核心知道驅動音頻流的高分辨率時鐘的時間，並且它了解掛鐘時間之間的預期關係和直播時間。它的行為類似於基於這些時間關係+與端點時鐘的定期同步的軟實時系統。 ※ 是的，S/PDIF 信號以自己的速度傳送樣本。異步重採樣是 DAC 用來解決這個問題的一種技術，但還有其他技術。可以簡單地忽略這個問題。這是一個消費級解決方案，但您完全可以僅使用傳入的 S/PDIF 信號來驅動整個過程並忽略（或省略）內部時鐘。一些 DAC 會緩慢調整其內部時鐘以適應輸入速率，使用小型緩衝區來防止溢出/欠載，然後重新計時數據輸出。我知道 Meridian 產品就是這樣工作的，但它們並不是唯一的產品。我猜測 MSB 使用了類似的方法（知道他們製作了梯形 DAC）及其營銷材料 8表明我是正確的。已經內置了大過採樣級的 DAC 可以協調現有重採樣過程中的時鐘差異。ESS Sabre 的技術文檔是支持 USB DSD 的 DAC 中非常常見的芯片，在本文檔的第 III-B 節中對此進行了討論 9。我的理解是，這是基於 Sigma-Delta 的 DAC 最常見的方法。為什麼這樣可以？因為這種轉換不會對信號質量造成實質性損害，因為過採樣率非常高。 ESS Sabre 正在對您的信號進行異步重新採樣，頻率約為 40mHz。與從 44100->44100.005 相比，這對質量的影響要小得多。 ※ 實際上沒有數據請求 - 服務器正在根據其自己的周期性同步對主時鐘進行建模，並使用它來驅動傳出數據速率。該技術簡化了主區域和從區域之間的協議級別差異，因為它們都可以使用相同的原語來管理流。只有一個額外的命令（“與遠程時鐘同步”）用於從站。每個端點都有幾秒鐘的緩衝區，並且緩衝區保持在半滿左右，因此，如果數據暫時太快或太慢，就有時間使時鐘保持一致，而不會超限或不足。從設備使用與服務器引導傳輸速率相同的機制來同步（“恢復”）主設備的時鐘。時鐘誤差測量通過響應緩慢的低通濾波器，因為當測量有噪聲時，此類系統容易出現振盪或過度校正。每個從屬設備都知道自己“領先”或“落後”多少，並且可以相應地進行調整。 Async SRC 是一種可以使用的技術，但不是唯一的選擇。我們的默認實現使用一種稱為“ 填充”和“刪除”樣本的技術 - 基本上是插入或刪除單個樣本。與典型的實現相比，我們的實現有所改進，因為它嘗試定位流中的位置來執行可聽度較小的插入/刪除，並且它使用 RNG 來定位校正，因為周期性聲音更容易挑選出來。我更喜歡這種方法，因為校正不會影響音頻，除非它們發生（使用異步 SRC，會產生持續的效果，並且以非常高的質量水平執行異步 SRC 非常昂貴）。在沒有太多 CPU 空間的低功耗端點上使用此方法也更實用。我們一直在考慮將漂移調整轉移到服務器的想法，這可以允許更密集/更昂貴的技術，因為我們有更多可用的 CPU 資源。還有一些願望可能支持跨不同技術的分組播放，這幾乎肯定會引導我們朝這個方向發展，因為每個人的系統工作方式都有點不同。 ※ 傳送過程基本就是在填充與提取 Buffer，過去我在 WASAPI 相關討論串中也提過Ｑ：因此，如果 RAAT 的設計方式意味著唯一“相關”時鐘是 DAC 本身中的一個實現（假設 Roon 端點為 USB DAC），那麼專用 PCIe USB 板上的所有那些深奧的 USB 時鐘發生器和高端時鐘都可以從技術上講，find 沒有執行任何有用的功能 RAAT 是一種網絡協議。它將數據從服務器（Roon Core）傳送到設備（例如，在最純粹的情況下）——網絡 DAC。當我們在這裡比較時鐘相關性時，我們是將蘋果與其他網絡協議進行比較——其中許多協議使計算機的時鐘以 RAAT 避免的方式成為音頻鏈的固有部分。當您開始插入附加元件（USB、S/PDIF 發生器、“USB 時鐘恢復器”或其他任何元件）時，批判性、徹底且具體地思考每個方面的工作原理非常重要。這些考慮因素完全獨立於 RAAT，並且是其他系統的特徵。RAAT 不會將其手指伸向 USB DAC，也不會從根本上改變 USB 的工作方式。在這種情況下討論時鐘和相關概念最令人沮喪的事情之一是它非常複雜，並且存在揮手、濫用或混淆術語的傾向。許多人從營銷來源獲取信息，有時這些營銷來源對技術細節的處理又快又松。例如，在您的問題中，您正在談論以完全不同的方式影響系統的各種時鐘，並認為也許我們對一種時鐘的討論也適用於其他時鐘。這種混亂部分是你們造成的，部分是我們造成的，但它很好地代表了總體情況。／關於 DAC 時鐘中的抖動如何只會在數模轉換期間導致失真，有一個相對容易理解的概念。我經常看到這種解釋被錯誤地應用於 USB 時鐘恢復器和其他增強產品。這並不是說所有時鐘都沒有可測量的抖動，或者這些測量結果無法改進，只是它們的抖動數並不通過相同的機制與聲音質量相關。根據 USB 規範，接收設備不應該關心這些差異，只要它們在規范范圍內即可。如果USB設備需要計算機生成遠遠超出USB規範要求的USB信號才能實現其全部性能，那麼設備設計人員真的完成了工作嗎？ ※ Ｑ：這好像是@加斯曼的問題仍然沒有答案，除非已經給出的答案相當於：“也許，但前提是這些輔助設備允許 Roon 訪問修改後的/新的 DAC 時鐘信號。” 這是一個公平的總結嗎@ 布萊恩？這個總結就是我上面警告的那種混亂的一個例子。如果您仔細考慮這些設備的實現細節（如果您還沒有，請閱讀並充分消化我在上面發布的 John Swenson 的鏈接，該鏈接解釋了一種此類產品並為進一步理解提供了一個良好的框架），很明顯這些設備是在低級別代理 USB 數據包，而不是 USB 音頻協議本身。這意味著無需考慮“授予訪問權限”或“干擾”。Roon 通過這些設備查看 DAC 的時鐘，就像通過任何其他 USB 集線器一樣。 100% 明確：此類設備中完成的時鐘恢復與音頻時鐘無關。它們在不與音頻播放或音頻採樣時鐘同步耦合的層中對 USB 數據傳輸位進行時鐘恢復。Ｑ：我想就是這樣@加斯曼的問題是：Roon 使用 DAC 時鐘信號將音頻流拉至網絡音頻適配器時會忽略單獨的時鐘或其他 USB 增強功能嗎？既然答案似乎是“也許”，也許你們可以指出一些這樣的“增強”產品，它們能夠為 Roon 提供增強的時鐘信號以用作參考時鐘？也許在此類產品中尋找特定的功能/技術可以幫助我們確定它們是否被 Roon 忽略？之所以@加斯曼的問題沒有得到明確的答案是因為它使用“時鐘”這個詞的方式比他引用的我最初的陳述更不精確，這造成了歧義。我說的是採樣時鐘，它不屬於這些 USB 增強器產品的範圍。這就是為什麼我開始解釋系統中的一些不同時鐘，而不是直接回答一個令人困惑的問題。 “為 Roon 提供增強時鐘信號以用作參考時鐘”的想法完全沒有意義。這東西不是這樣工作的。如果 USB/數據傳輸時鐘和音頻時鐘的概念混淆在一起，就不可能對此進行清晰的討論。 ※ Ｑ：似乎即使在最簡單的 PC 音頻鏈中，在任何給定時刻都有許多“時鐘”在運行，而不僅僅是 DAC 中的時鐘這是事實，事實上，在許多 DAC 中，根據產品的設計及其功能集運行多個時鐘。例如，具有集成流卡的 DAC 將具有管理 DAC 本身的時鐘（或多個時鐘）以及在流卡上運行處理器的單獨時鐘（或多個時鐘）。Ｑ：人們可以合理地假設，從理論上和可測量上來說，其中任何一個“更好”（更準確，噪音更少），數字音樂的解碼和播放就會“更好”，甚至可能是可聽的然而，這並不完全正確。RAAT 的運行級別高於網絡硬件本身。為了大大簡化事情，它在核心上分配一個緩衝區，在端點上分配另一個緩衝區。端點緩衝區可以位於連接的計算機、流媒體卡等中。核心將數據放入其本地緩衝區，DAC 使用任何適當的接口從其本地緩衝區中提取數據。核心僅看到其本地緩衝區，DAC 也僅看到其本地緩衝區。由 RAAT 協議來管理兩個緩衝區之間的數據傳輸，並確保兩個緩衝區都不會太空或太滿。為什麼這很重要？嗯，DAC 只能從本地緩衝區提取數據，因此它不關心上游管道。核心只能將數據放入其本地緩衝區，因為它不關心下游管道。 RAAT 管理兩者之間的數據傳輸，為了確保從核心到 DAC 的所有位完好無損，它使用網絡本身提供的較低級別的設施來確保完整性。如果數據包丟失，則會發送新的數據包並按正確的順序放入緩衝區。腐敗？一樣。在大多數情況下，緩衝區足夠大，以便在 DAC 不耗盡數據或內核填滿其緩衝區的情況下進行糾錯過程。請記住，我在這裡非常謹慎地使用“數據”一詞，因為這就是此時的音樂。它是一個位流，是正在播放的文件的副本。這是一個異步過程，對 DAC 的模擬輸出沒有影響。RAAT（和網絡堆棧）正在促進核心和端點之間的非常聊天的對話。他們確保文件（不超過緩衝區的大小）從核心複製到端點。傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零，因為 DAC 所做的所有操作都是從本地內存緩衝區播放。它不知道，也不關心這些位在進入緩衝區之前發生了什麼。如果交換機或網絡接口中的時鐘滿足傳輸機制的規範，則數據傳輸過程幾乎不會出現任何問題。如果他們不這樣做，那麼就會出現更大的問題。這是一個異步過程。根據定義，傳輸過程的計時（時鐘）與解碼過程完全分開。緩衝區將以可變速率填充和清空，但只要 DAC 緩衝區中有足夠的空間，播放就會可靠地繼續。這里區分的關鍵是數據和信號之間的區別。正在播放的文件不會變成信號，直到其位實時通過 DAC 。在從 DAC（或端點）的本地緩衝區中提取這些位之前，這些位與用於文檔、圖像甚至本文的位沒有什麼不同。我理解發燒友不斷嘗試“改進”事物的願望，而這種行為確實是這種愛好的基礎。這在過去更容易做到，因為大多數與物理和變化相關的概念不僅很容易被證明，而且可以用一些邏輯解釋來支持。數字根本不是這樣，因為許多概念是反直覺的，而且解釋要復雜得多。如果將流媒體混入其中，問題就會變得更糟。大多數音頻設備製造商對網絡如何運作以及網絡可能或可能不會對實際播放產生影響幾乎不了解。可悲的是，這對那些花費辛苦賺來的錢來解決實際上不存在的問題的消費者產生了負面影響。 ※ Ｑ：根據您的描述，通過將核心和播放器放在同一設備（NAS 上的文件）中從等式中刪除 RAAT 是否會對 SQ 產生任何影響？理論上，只要 DAC 手頭上有足夠的數據來以適當的速率執行解碼，數據緩衝區的維護方式就不會有什麼影響。問題是，當您不控制所有變量時，將緩衝區保持在適當的水平實際上是非常困難的。／為了維護系統，您需要主動監控和調整龍頭上的閥門以維持填充率，以確保永遠不會讓水位低於設定的最低水平。您還需要確保進行調整以確保不會超過安全最大值。您需要對高水位線和低水位線進行預測，並對通過龍頭可用的水量變化和實際排水率的微小變化做出反應。這就是 RAAT 正在做的事情。它對 DAC（排水管）的時鐘速率進行建模，以了解浴缸是如何被清空的。它還對網絡性能做出響應，以確保填充率不會允許緩衝區溢出或不足。它甚至比這更複雜，因為核心側還有一個桶，通過網絡“排出”到 DAC 側的桶，並且桶的大小根據所涉及的採樣率而不同。現在想像一下對區域進行分組是多麼複雜（特別是如果每個區域有不同的採樣率要求）。區域浴缸需要以絕對鎖定的步驟排水才能使其工作，但您無法控制連接浴缸的管道！Ｑ：或者在正常運行的網絡環境中，RAAT 是否足夠高效以保持所有緩衝區處於滿狀態？賓果，關鍵確實是一個正常運行的網絡環境。這並不意味著具有數據中心質量或無限帶寬，而是足以滿足在任何給定時間傳輸音頻數據以及任何其他用途的需求。這也不意味著您需要一堆調整設備和適配器才能使其聽起來更好。它只需要滿足標準，而且這並不難實現（儘管許多與音頻相關的網絡東西[電纜、濾波器、時鐘器等]幾乎忽略了標準）。請記住，與典型的千兆位鏈路（即使是非常糟糕的鏈路）上的可用帶寬相比，音頻比特率根本不算什麼。DXD 約為 20Mbit/秒。DSD512 約為 45Mbit/秒。千兆以太網是 1000Mbit/秒！只要網絡可靠並且能夠處理數據速率，那麼 RAAT 就可以工作（而且效果非常好）。去掉可靠性，它就會開始變得醜陋。 ※ Brian 提到了時鐘質量與一致性，並指出他的帖子中的討論與後者相關。大多數發燒友對時鐘的討論都與時鐘質量（精度）有關，因為這會影響 DAC 的運行速率。這裡的問題是，許多人看到“時鐘”並假設討論與抖動或其他一些可聽的東西有關。事實並非如此。時鐘質量涉及時鐘的準確性，即對於任何給定的時鐘“滴答聲”，後續的“滴答聲”是否恰好在正確的時間發生，或者是有點早或晚了。過早或過晚都可能會造成不良影響，因為它會對 DAC 輸出的模擬信號產生潛在的聽覺影響。 RAAT 根本不處理這個問題。時鐘一致性處理兩個或多個時鐘之間的差異（如果同時啟動並隨著時間的推移進行觀察）。在完美的世界中，您可以並排放置兩個相同的時鐘，在 time=0 時啟動它們，並觀察它們永遠保持彼此同步。在現實世界中，這不會發生。曾經。這兩個時鐘可能非常非常接近，但它們之間總會有一些偏差。（這是因為時鐘始終基於對物理現象的觀察，物理系統的微小差異總是會導致測量結果的差異）。對於數字音頻來說，這種漂移可能是無關緊要的，而且在許多情況下確實如此。如果漂移（無論是總漂移還是樣本間漂移（抖動））足夠小，則不會存在於對音頻有任何影響的頻率上。出於數據管理的目的，這是一個大問題。對於 DAC，輸出是開放式的，因為它可以運行得慢或快，並且輸入的位將使其作為模擬信號輸出。由於與時鐘相關的異常，信號可能會失真，但沒有什麼可以阻止 DAC 從一側獲取比特並在另一側輸出模擬。當您談論在緩衝區之間移動數據時，您正在處理一個完全封閉的系統。假設您有兩個緩衝區（A 和 B），每個緩衝區都由單獨的時鐘（cA 和 cB）控制。數據以 cA 定義的速率移出緩衝區 A，緩衝區 B 和 cB 也以相同的速率移出。在這種情況下，緩衝器 B 為 DAC 的輸入供電，而 cB 則管理 B 的漏極以及 DAC 本身。這兩個緩衝區具有已定義的大小，並且出於實際目的應保持盡可能合理的小。現在，假設兩個時鐘頻率相同，讓該系統開始運行。對於從 A 複製到 B 的每個樣本，還應該有一個樣本從 B 移動到 DAC。如果兩個時鐘完全一致（彼此同步），那麼這工作得很好並且沒有問題。這在現實世界中永遠不會發生。其中一個時鐘總是比另一個時鐘快，如果允許系統運行足夠長的時間，那麼就會發生以下兩件事之一。如果時鐘 A 很快，那麼 B 的填充速度將快於耗儘速度，最終將被填滿。裝滿後，您必須弄清楚如何處理下一個樣品。如果時鐘 B 很快，那麼 B 的清空速度將快於其填充速度，DAC 最終將耗盡數據。處理時鐘一致性試圖以最有效的方式解決這個問題，使得 B 永遠不會被填滿或完全清空。這就是 RAAT 正在解決的問題，您會注意到它與時鐘質量無關，而時鐘質量正是發燒友在談論抖動時所關心的問題。在像 Roon 這樣的系統中，有數十個（或數百個）緩衝區在運行，所有緩衝區都由不同的時鐘驅動。為了確保 DAC 旁邊的緩衝區永遠不會耗盡數據或溢出，RAAT 需要觀察控制該緩衝區的時鐘。在某些情況下，這根本無法做到，因此 RAAT 需要監視盡可能靠近 DAC 的緩衝區。如果 Roon 可以對遠處緩衝區的行為進行建模，那麼就可以確保它始終以不會允許其溢出或耗盡的速率發送數據。 ※ -- 人間五十年、化天のうちを比ぶれば、夢幻の如くなり ^,,,^ 一度生を享け、滅せぬもののあるべきか (ミ‵ω′)\m/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.36.215.60 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689079757.A.F41.html

推

elguapo

07/11 21:11, 9月前 , 1^F

07/11 21:11, 1^F

→

elguapo

07/11 21:11, 9月前 , 2^F

07/11 21:11, 2^F

→

elguapo

07/11 21:11, 9月前 , 3^F

07/11 21:11, 3^F