作者
標題 Re: [心得] 運用 Chrony 對時工具提升音訊品質
時間 Tue Jul 11 20:49:13 2023
標題 Re: [心得] 運用 Chrony 對時工具提升音訊品質
時間 Tue Jul 11 20:49:13 2023
RAAT and clock ownership
https://community.roonlabs.com/t/raat-and-clock-ownership/6915
RAAT and clock ownership - 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)
這是個很長的討論串，但內容應該不太複雜
把重點放在兩位 Roon 員工對使用者提問的回答
brian | Brian Luczkiewicz | Roon Labs Founder
AMP | Andrew P | Roon Labs
在此為了方便閱讀用 Google 英翻中，挑重點不然篇幅太長，有疑慮請參照原文
其實對本話題有興趣的朋友，都應該要去看完整原文
只有完整從頭看到尾，才能真正理解 Roon 在講什麼
在此我只能簡單的拉出一些關鍵段落
只有完整從頭看到尾，才能真正理解 Roon 在講什麼
在此我只能簡單的拉出一些關鍵段落
但其實大部分的內容都很重要，且有前後連續性（刪很多還是很多
※
關於音頻時鐘的大多數討論都集中在時鐘質量，而不是時鐘一致性。本次討論是關於後者
的。“抖動”這個詞不屬於本次討論的範圍。RAAT 對該領域沒有影響。它異步移動音頻
緩衝區，就像 USB 一樣。它不參與生成驅動 DAC 的時鐘信號。
的。“抖動”這個詞不屬於本次討論的範圍。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表明我是
正確的。
後重新計時數據輸出。我知道 Meridian 產品就是這樣工作的，但它們並不是唯一的產品
。我猜測 MSB 使用了類似的方法（知道他們製作了梯形 DAC）及其營銷材料 8表明我是
正確的。
已經內置了大過採樣級的 DAC 可以協調現有重採樣過程中的時鐘差異。ESS Sabre 的技
術文檔是支持 USB DSD 的 DAC 中非常常見的芯片，在本文檔的第 III-B 節中對此進行
了討論 9。我的理解是，這是基於 Sigma-Delta 的 DAC 最常見的方法。
術文檔是支持 USB DSD 的 DAC 中非常常見的芯片，在本文檔的第 III-B 節中對此進行
了討論 9。我的理解是，這是基於 Sigma-Delta 的 DAC 最常見的方法。
為什麼這樣可以？因為這種轉換不會對信號質量造成實質性損害，因為過採樣率非常高。
ESS Sabre 正在對您的信號進行異步重新採樣，頻率約為 40mHz。與從
44100->44100.005 相比，這對質量的影響要小得多。
※
實際上沒有數據請求 - 服務器正在根據其自己的周期性同步對主時鐘進行建模，並使用
它來驅動傳出數據速率。該技術簡化了主區域和從區域之間的協議級別差異，因為它們都
可以使用相同的原語來管理流。只有一個額外的命令（“與遠程時鐘同步”）用於從站。
每個端點都有幾秒鐘的緩衝區，並且緩衝區保持在半滿左右，因此，如果數據暫時太快或
太慢，就有時間使時鐘保持一致，而不會超限或不足。
它來驅動傳出數據速率。該技術簡化了主區域和從區域之間的協議級別差異，因為它們都
可以使用相同的原語來管理流。只有一個額外的命令（“與遠程時鐘同步”）用於從站。
每個端點都有幾秒鐘的緩衝區，並且緩衝區保持在半滿左右，因此，如果數據暫時太快或
太慢，就有時間使時鐘保持一致，而不會超限或不足。
從設備使用與服務器引導傳輸速率相同的機制來同步（“恢復”）主設備的時鐘。時鐘誤
差測量通過響應緩慢的低通濾波器，因為當測量有噪聲時，此類系統容易出現振盪或過度
校正。每個從屬設備都知道自己“領先”或“落後”多少，並且可以相應地進行調整。
差測量通過響應緩慢的低通濾波器，因為當測量有噪聲時，此類系統容易出現振盪或過度
校正。每個從屬設備都知道自己“領先”或“落後”多少，並且可以相應地進行調整。
Async SRC 是一種可以使用的技術，但不是唯一的選擇。我們的默認實現使用一種稱為“
填充”和“刪除”樣本的技術 - 基本上是插入或刪除單個樣本。與典型的實現相比，我
們的實現有所改進，因為它嘗試定位流中的位置來執行可聽度較小的插入/刪除，並且它
使用 RNG 來定位校正，因為周期性聲音更容易挑選出來。
填充”和“刪除”樣本的技術 - 基本上是插入或刪除單個樣本。與典型的實現相比，我
們的實現有所改進，因為它嘗試定位流中的位置來執行可聽度較小的插入/刪除，並且它
使用 RNG 來定位校正，因為周期性聲音更容易挑選出來。
我更喜歡這種方法，因為校正不會影響音頻，除非它們發生（使用異步 SRC，會產生持續
的效果，並且以非常高的質量水平執行異步 SRC 非常昂貴）。在沒有太多 CPU 空間的低
功耗端點上使用此方法也更實用。
的效果，並且以非常高的質量水平執行異步 SRC 非常昂貴）。在沒有太多 CPU 空間的低
功耗端點上使用此方法也更實用。
我們一直在考慮將漂移調整轉移到服務器的想法，這可以允許更密集/更昂貴的技術，因
為我們有更多可用的 CPU 資源。還有一些願望可能支持跨不同技術的分組播放，這幾乎
肯定會引導我們朝這個方向發展，因為每個人的系統工作方式都有點不同。
為我們有更多可用的 CPU 資源。還有一些願望可能支持跨不同技術的分組播放，這幾乎
肯定會引導我們朝這個方向發展，因為每個人的系統工作方式都有點不同。
※ 傳送過程基本就是在填充與提取 Buffer，過去我在 WASAPI 相關討論串中也提過
Ｑ：因此，如果 RAAT 的設計方式意味著唯一“相關”時鐘是 DAC 本身中的一個實現（假設
Roon 端點為 USB DAC），那麼專用 PCIe USB 板上的所有那些深奧的 USB 時鐘發生器
和高端時鐘都可以從技術上講，find 沒有執行任何有用的功能
RAAT 是一種網絡協議。它將數據從服務器（Roon Core）傳送到設備（例如，在最純粹的
情況下）——網絡 DAC。當我們在這裡比較時鐘相關性時，我們是將蘋果與其他網絡協議
進行比較——其中許多協議使計算機的時鐘以 RAAT 避免的方式成為音頻鏈的固有部分。
當您開始插入附加元件（USB、S/PDIF 發生器、“USB 時鐘恢復器”或其他任何元件）時
，批判性、徹底且具體地思考每個方面的工作原理非常重要。這些考慮因素完全獨立於
情況下）——網絡 DAC。當我們在這裡比較時鐘相關性時，我們是將蘋果與其他網絡協議
進行比較——其中許多協議使計算機的時鐘以 RAAT 避免的方式成為音頻鏈的固有部分。
當您開始插入附加元件（USB、S/PDIF 發生器、“USB 時鐘恢復器”或其他任何元件）時
，批判性、徹底且具體地思考每個方面的工作原理非常重要。這些考慮因素完全獨立於
RAAT，並且是其他系統的特徵。RAAT 不會將其手指伸向 USB DAC，也不會從根本上改變
USB 的工作方式。
在這種情況下討論時鐘和相關概念最令人沮喪的事情之一是它非常複雜，並且存在揮手、
濫用或混淆術語的傾向。許多人從營銷來源獲取信息，有時這些營銷來源對技術細節的處
理又快又松。
濫用或混淆術語的傾向。許多人從營銷來源獲取信息，有時這些營銷來源對技術細節的處
理又快又松。
例如，在您的問題中，您正在談論以完全不同的方式影響系統的各種時鐘，並認為也許我
們對一種時鐘的討論也適用於其他時鐘。這種混亂部分是你們造成的，部分是我們造成的
，但它很好地代表了總體情況。
們對一種時鐘的討論也適用於其他時鐘。這種混亂部分是你們造成的，部分是我們造成的
，但它很好地代表了總體情況。
／
關於 DAC 時鐘中的抖動如何只會在數模轉換期間導致失真，有一個相對容易理解的概念
。我經常看到這種解釋被錯誤地應用於 USB 時鐘恢復器和其他增強產品。這並不是說所
有時鐘都沒有可測量的抖動，或者這些測量結果無法改進，只是它們的抖動數並不通過相
同的機制與聲音質量相關。
。我經常看到這種解釋被錯誤地應用於 USB 時鐘恢復器和其他增強產品。這並不是說所
有時鐘都沒有可測量的抖動，或者這些測量結果無法改進，只是它們的抖動數並不通過相
同的機制與聲音質量相關。
根據 USB 規範，接收設備不應該關心這些差異，只要它們在規范范圍內即可。如果USB設
備需要計算機生成遠遠超出USB規範要求的USB信號才能實現其全部性能，那麼設備設計人
員真的完成了工作嗎？
備需要計算機生成遠遠超出USB規範要求的USB信號才能實現其全部性能，那麼設備設計人
員真的完成了工作嗎？
※
Ｑ：這好像是@加斯曼的問題仍然沒有答案，除非已經給出的答案相當於：“也許，但前提是
這些輔助設備允許 Roon 訪問修改後的/新的 DAC 時鐘信號。” 這是一個公平的總結嗎@
布萊恩？
這個總結就是我上面警告的那種混亂的一個例子。
如果您仔細考慮這些設備的實現細節（如果您還沒有，請閱讀並充分消化我在上面發布的
John Swenson 的鏈接，該鏈接解釋了一種此類產品並為進一步理解提供了一個良好的框
架），很明顯這些設備是在低級別代理 USB 數據包，而不是 USB 音頻協議本身。
John Swenson 的鏈接，該鏈接解釋了一種此類產品並為進一步理解提供了一個良好的框
架），很明顯這些設備是在低級別代理 USB 數據包，而不是 USB 音頻協議本身。
這意味著無需考慮“授予訪問權限”或“干擾”。Roon 通過這些設備查看 DAC 的時鐘，
就像通過任何其他 USB 集線器一樣。
100% 明確：此類設備中完成的時鐘恢復與音頻時鐘無關。它們在不與音頻播放或音頻採樣
時鐘同步耦合的層中對 USB 數據傳輸位進行時鐘恢復。
Ｑ：我想就是這樣@加斯曼的問題是：Roon 使用 DAC 時鐘信號將音頻流拉至網絡音頻適配器
時會忽略單獨的時鐘或其他 USB 增強功能嗎？既然答案似乎是“也許”，也許你們可以
指出一些這樣的“增強”產品，它們能夠為 Roon 提供增強的時鐘信號以用作參考時鐘？
也許在此類產品中尋找特定的功能/技術可以幫助我們確定它們是否被 Roon 忽略？
指出一些這樣的“增強”產品，它們能夠為 Roon 提供增強的時鐘信號以用作參考時鐘？
也許在此類產品中尋找特定的功能/技術可以幫助我們確定它們是否被 Roon 忽略？
之所以@加斯曼的問題沒有得到明確的答案是因為它使用“時鐘”這個詞的方式比他引用
的我最初的陳述更不精確，這造成了歧義。我說的是採樣時鐘，它不屬於這些 USB 增強
器產品的範圍。
的我最初的陳述更不精確，這造成了歧義。我說的是採樣時鐘，它不屬於這些 USB 增強
器產品的範圍。
這就是為什麼我開始解釋系統中的一些不同時鐘，而不是直接回答一個令人困惑的問題。
“為 Roon 提供增強時鐘信號以用作參考時鐘”的想法完全沒有意義。這東西不是這樣工
作的。如果 USB/數據傳輸時鐘和音頻時鐘的概念混淆在一起，就不可能對此進行清晰的
討論。
作的。如果 USB/數據傳輸時鐘和音頻時鐘的概念混淆在一起，就不可能對此進行清晰的
討論。
※
Ｑ：似乎即使在最簡單的 PC 音頻鏈中，在任何給定時刻都有許多“時鐘”在運行，而不僅僅
是 DAC 中的時鐘
這是事實，事實上，在許多 DAC 中，根據產品的設計及其功能集運行多個時鐘。例如，
具有集成流卡的 DAC 將具有管理 DAC 本身的時鐘（或多個時鐘）以及在流卡上運行處理
器的單獨時鐘（或多個時鐘）。
具有集成流卡的 DAC 將具有管理 DAC 本身的時鐘（或多個時鐘）以及在流卡上運行處理
器的單獨時鐘（或多個時鐘）。
Ｑ：人們可以合理地假設，從理論上和可測量上來說，其中任何一個“更好”（更準確，噪音
更少），數字音樂的解碼和播放就會“更好”，甚至可能是可聽的
然而，這並不完全正確。RAAT 的運行級別高於網絡硬件本身。為了大大簡化事情，它在
核心上分配一個緩衝區，在端點上分配另一個緩衝區。端點緩衝區可以位於連接的計算機
、流媒體卡等中。核心將數據放入其本地緩衝區，DAC 使用任何適當的接口從其本地緩衝
區中提取數據。核心僅看到其本地緩衝區，DAC 也僅看到其本地緩衝區。由 RAAT 協議來
管理兩個緩衝區之間的數據傳輸，並確保兩個緩衝區都不會太空或太滿。
核心上分配一個緩衝區，在端點上分配另一個緩衝區。端點緩衝區可以位於連接的計算機
、流媒體卡等中。核心將數據放入其本地緩衝區，DAC 使用任何適當的接口從其本地緩衝
區中提取數據。核心僅看到其本地緩衝區，DAC 也僅看到其本地緩衝區。由 RAAT 協議來
管理兩個緩衝區之間的數據傳輸，並確保兩個緩衝區都不會太空或太滿。
為什麼這很重要？
嗯，DAC 只能從本地緩衝區提取數據，因此它不關心上游管道。核心只能將數據放入其本
地緩衝區，因為它不關心下游管道。
RAAT 管理兩者之間的數據傳輸，為了確保從核心到 DAC 的所有位完好無損，它使用網絡
本身提供的較低級別的設施來確保完整性。如果數據包丟失，則會發送新的數據包並按正
確的順序放入緩衝區。腐敗？一樣。在大多數情況下，緩衝區足夠大，以便在 DAC 不耗
盡數據或內核填滿其緩衝區的情況下進行糾錯過程。
本身提供的較低級別的設施來確保完整性。如果數據包丟失，則會發送新的數據包並按正
確的順序放入緩衝區。腐敗？一樣。在大多數情況下，緩衝區足夠大，以便在 DAC 不耗
盡數據或內核填滿其緩衝區的情況下進行糾錯過程。
請記住，我在這裡非常謹慎地使用“數據”一詞，因為這就是此時的音樂。它是一個位流
，是正在播放的文件的副本。這是一個異步過程，對 DAC 的模擬輸出沒有影響。RAAT（
和網絡堆棧）正在促進核心和端點之間的非常聊天的對話。他們確保文件（不超過緩衝區
的大小）從核心複製到端點。
，是正在播放的文件的副本。這是一個異步過程，對 DAC 的模擬輸出沒有影響。RAAT（
和網絡堆棧）正在促進核心和端點之間的非常聊天的對話。他們確保文件（不超過緩衝區
的大小）從核心複製到端點。
傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零，因為 DAC 所做的所有操作都是從
本地內存緩衝區播放。它不知道，也不關心這些位在進入緩衝區之前發生了什麼。如果交
換機或網絡接口中的時鐘滿足傳輸機制的規範，則數據傳輸過程幾乎不會出現任何問題。
如果他們不這樣做，那麼就會出現更大的問題。
本地內存緩衝區播放。它不知道，也不關心這些位在進入緩衝區之前發生了什麼。如果交
換機或網絡接口中的時鐘滿足傳輸機制的規範，則數據傳輸過程幾乎不會出現任何問題。
如果他們不這樣做，那麼就會出現更大的問題。
這是一個異步過程。根據定義，傳輸過程的計時（時鐘）與解碼過程完全分開。緩衝區將
以可變速率填充和清空，但只要 DAC 緩衝區中有足夠的空間，播放就會可靠地繼續。
這里區分的關鍵是數據和信號之間的區別。正在播放的文件不會變成信號，直到其位實時
通過 DAC 。在從 DAC（或端點）的本地緩衝區中提取這些位之前，這些位與用於文檔、
圖像甚至本文的位沒有什麼不同。
通過 DAC 。在從 DAC（或端點）的本地緩衝區中提取這些位之前，這些位與用於文檔、
圖像甚至本文的位沒有什麼不同。
我理解發燒友不斷嘗試“改進”事物的願望，而這種行為確實是這種愛好的基礎。這在過
去更容易做到，因為大多數與物理和變化相關的概念不僅很容易被證明，而且可以用一些
邏輯解釋來支持。數字根本不是這樣，因為許多概念是反直覺的，而且解釋要復雜得多。
如果將流媒體混入其中，問題就會變得更糟。大多數音頻設備製造商對網絡如何運作以及
網絡可能或可能不會對實際播放產生影響幾乎不了解。可悲的是，這對那些花費辛苦賺來
的錢來解決實際上不存在的問題的消費者產生了負面影響。
去更容易做到，因為大多數與物理和變化相關的概念不僅很容易被證明，而且可以用一些
邏輯解釋來支持。數字根本不是這樣，因為許多概念是反直覺的，而且解釋要復雜得多。
如果將流媒體混入其中，問題就會變得更糟。大多數音頻設備製造商對網絡如何運作以及
網絡可能或可能不會對實際播放產生影響幾乎不了解。可悲的是，這對那些花費辛苦賺來
的錢來解決實際上不存在的問題的消費者產生了負面影響。
※
Ｑ：根據您的描述，通過將核心和播放器放在同一設備（NAS 上的文件）中從等式中刪除
RAAT 是否會對 SQ 產生任何影響？
理論上，只要 DAC 手頭上有足夠的數據來以適當的速率執行解碼，數據緩衝區的維護方
式就不會有什麼影響。問題是，當您不控制所有變量時，將緩衝區保持在適當的水平實際
上是非常困難的。
式就不會有什麼影響。問題是，當您不控制所有變量時，將緩衝區保持在適當的水平實際
上是非常困難的。
／
為了維護系統，您需要主動監控和調整龍頭上的閥門以維持填充率，以確保永遠不會讓水
位低於設定的最低水平。您還需要確保進行調整以確保不會超過安全最大值。您需要對高
水位線和低水位線進行預測，並對通過龍頭可用的水量變化和實際排水率的微小變化做出
反應。
位低於設定的最低水平。您還需要確保進行調整以確保不會超過安全最大值。您需要對高
水位線和低水位線進行預測，並對通過龍頭可用的水量變化和實際排水率的微小變化做出
反應。
這就是 RAAT 正在做的事情。它對 DAC（排水管）的時鐘速率進行建模，以了解浴缸是如
何被清空的。它還對網絡性能做出響應，以確保填充率不會允許緩衝區溢出或不足。
它甚至比這更複雜，因為核心側還有一個桶，通過網絡“排出”到 DAC 側的桶，並且桶
的大小根據所涉及的採樣率而不同。
現在想像一下對區域進行分組是多麼複雜（特別是如果每個區域有不同的採樣率要求）。
區域浴缸需要以絕對鎖定的步驟排水才能使其工作，但您無法控制連接浴缸的管道！
Ｑ：或者在正常運行的網絡環境中，RAAT 是否足夠高效以保持所有緩衝區處於滿狀態？
賓果，關鍵確實是一個正常運行的網絡環境。這並不意味著具有數據中心質量或無限帶寬
，而是足以滿足在任何給定時間傳輸音頻數據以及任何其他用途的需求。這也不意味著您
需要一堆調整設備和適配器才能使其聽起來更好。它只需要滿足標準，而且這並不難實現
（儘管許多與音頻相關的網絡東西[電纜、濾波器、時鐘器等]幾乎忽略了標準）。
，而是足以滿足在任何給定時間傳輸音頻數據以及任何其他用途的需求。這也不意味著您
需要一堆調整設備和適配器才能使其聽起來更好。它只需要滿足標準，而且這並不難實現
（儘管許多與音頻相關的網絡東西[電纜、濾波器、時鐘器等]幾乎忽略了標準）。
請記住，與典型的千兆位鏈路（即使是非常糟糕的鏈路）上的可用帶寬相比，音頻比特率
根本不算什麼。DXD 約為 20Mbit/秒。DSD512 約為 45Mbit/秒。千兆以太網是
1000Mbit/秒！
只要網絡可靠並且能夠處理數據速率，那麼 RAAT 就可以工作（而且效果非常好）。去掉
可靠性，它就會開始變得醜陋。
※
Brian 提到了時鐘質量與一致性，並指出他的帖子中的討論與後者相關。大多數發燒友對
時鐘的討論都與時鐘質量（精度）有關，因為這會影響 DAC 的運行速率。這裡的問題是
，許多人看到“時鐘”並假設討論與抖動或其他一些可聽的東西有關。事實並非如此。
時鐘的討論都與時鐘質量（精度）有關，因為這會影響 DAC 的運行速率。這裡的問題是
，許多人看到“時鐘”並假設討論與抖動或其他一些可聽的東西有關。事實並非如此。
時鐘質量涉及時鐘的準確性，即對於任何給定的時鐘“滴答聲”，後續的“滴答聲”是否
恰好在正確的時間發生，或者是有點早或晚了。過早或過晚都可能會造成不良影響，因為
它會對 DAC 輸出的模擬信號產生潛在的聽覺影響。
恰好在正確的時間發生，或者是有點早或晚了。過早或過晚都可能會造成不良影響，因為
它會對 DAC 輸出的模擬信號產生潛在的聽覺影響。
RAAT 根本不處理這個問題。
時鐘一致性處理兩個或多個時鐘之間的差異（如果同時啟動並隨著時間的推移進行觀察）
。在完美的世界中，您可以並排放置兩個相同的時鐘，在 time=0 時啟動它們，並觀察它
們永遠保持彼此同步。在現實世界中，這不會發生。曾經。這兩個時鐘可能非常非常接近
，但它們之間總會有一些偏差。（這是因為時鐘始終基於對物理現象的觀察，物理系統的
微小差異總是會導致測量結果的差異）。
。在完美的世界中，您可以並排放置兩個相同的時鐘，在 time=0 時啟動它們，並觀察它
們永遠保持彼此同步。在現實世界中，這不會發生。曾經。這兩個時鐘可能非常非常接近
，但它們之間總會有一些偏差。（這是因為時鐘始終基於對物理現象的觀察，物理系統的
微小差異總是會導致測量結果的差異）。
對於數字音頻來說，這種漂移可能是無關緊要的，而且在許多情況下確實如此。如果漂移
（無論是總漂移還是樣本間漂移（抖動））足夠小，則不會存在於對音頻有任何影響的頻
率上。
（無論是總漂移還是樣本間漂移（抖動））足夠小，則不會存在於對音頻有任何影響的頻
率上。
出於數據管理的目的，這是一個大問題。
對於 DAC，輸出是開放式的，因為它可以運行得慢或快，並且輸入的位將使其作為模擬信
號輸出。由於與時鐘相關的異常，信號可能會失真，但沒有什麼可以阻止 DAC 從一側獲
取比特並在另一側輸出模擬。
號輸出。由於與時鐘相關的異常，信號可能會失真，但沒有什麼可以阻止 DAC 從一側獲
取比特並在另一側輸出模擬。
當您談論在緩衝區之間移動數據時，您正在處理一個完全封閉的系統。假設您有兩個緩衝
區（A 和 B），每個緩衝區都由單獨的時鐘（cA 和 cB）控制。數據以 cA 定義的速率移
出緩衝區 A，緩衝區 B 和 cB 也以相同的速率移出。在這種情況下，緩衝器 B 為 DAC
區（A 和 B），每個緩衝區都由單獨的時鐘（cA 和 cB）控制。數據以 cA 定義的速率移
出緩衝區 A，緩衝區 B 和 cB 也以相同的速率移出。在這種情況下，緩衝器 B 為 DAC
的輸入供電，而 cB 則管理 B 的漏極以及 DAC 本身。
這兩個緩衝區具有已定義的大小，並且出於實際目的應保持盡可能合理的小。
現在，假設兩個時鐘頻率相同，讓該系統開始運行。對於從 A 複製到 B 的每個樣本，還
應該有一個樣本從 B 移動到 DAC。如果兩個時鐘完全一致（彼此同步），那麼這工作得
很好並且沒有問題。這在現實世界中永遠不會發生。其中一個時鐘總是比另一個時鐘快，
如果允許系統運行足夠長的時間，那麼就會發生以下兩件事之一。
應該有一個樣本從 B 移動到 DAC。如果兩個時鐘完全一致（彼此同步），那麼這工作得
很好並且沒有問題。這在現實世界中永遠不會發生。其中一個時鐘總是比另一個時鐘快，
如果允許系統運行足夠長的時間，那麼就會發生以下兩件事之一。
如果時鐘 A 很快，那麼 B 的填充速度將快於耗儘速度，最終將被填滿。裝滿後，您必須
弄清楚如何處理下一個樣品。
如果時鐘 B 很快，那麼 B 的清空速度將快於其填充速度，DAC 最終將耗盡數據。
處理時鐘一致性試圖以最有效的方式解決這個問題，使得 B 永遠不會被填滿或完全清空
處理時鐘一致性試圖以最有效的方式解決這個問題，使得 B 永遠不會被填滿或完全清空
。這就是 RAAT 正在解決的問題，您會注意到它與時鐘質量無關，而時鐘質量正是發燒友
在談論抖動時所關心的問題。
在像 Roon 這樣的系統中，有數十個（或數百個）緩衝區在運行，所有緩衝區都由不同的
時鐘驅動。為了確保 DAC 旁邊的緩衝區永遠不會耗盡數據或溢出，RAAT 需要觀察控制該
緩衝區的時鐘。在某些情況下，這根本無法做到，因此 RAAT 需要監視盡可能靠近 DAC
時鐘驅動。為了確保 DAC 旁邊的緩衝區永遠不會耗盡數據或溢出，RAAT 需要觀察控制該
緩衝區的時鐘。在某些情況下，這根本無法做到，因此 RAAT 需要監視盡可能靠近 DAC
的緩衝區。
如果 Roon 可以對遠處緩衝區的行為進行建模，那麼就可以確保它始終以不會允許其溢出
或耗盡的速率發送數據。
※
--
人間五十年、化天のうちを比ぶれば、夢幻の如くなり
^,,,^ 一度生を享け、滅せぬもののあるべきか
(ミ‵ω′)\m/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.36.215.60 (臺灣)
※ 作者: Oswyn 2023-07-11 20:49:13
※ 文章代碼(AID): #1ahK_Dz1 (Audiophile)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689079757.A.F41.html
※ 同主題文章:
07-10 21:09
Re: [心得] 運用 Chrony 對時工具提升音訊品質
07-11 20:49
07-13 16:33
07-13 20:20
07-15 00:01
推 : 我不知道您能否接受我截圖給您的內容，那個是 Roon 創
辦人寫的。Roon 會綜合 endpoint 回傳的時鐘資料，去比對 Roon 本身的系統時鐘的差別，然後建立一個預測模型
，用這個模型去送信號。這時系統時鐘主宰信號發送，畢
竟這時的控制權是 Roon，不是 DAC。1F 07/11 21:11
辦人寫的。Roon 會綜合 endpoint 回傳的時鐘資料，去比對 Roon 本身的系統時鐘的差別，然後建立一個預測模型
，用這個模型去送信號。這時系統時鐘主宰信號發送，畢
竟這時的控制權是 Roon，不是 DAC。1F 07/11 21:11
我截出來的也是 Brian Luczkiewicz | Roon Labs Founder 跟另名員工所言
看完整串應該能理解，系統時鐘應該只跟維持 Buffer 吞吐有關
只要 Buffer 不欠載不溢出＆網路傳輸是正常的，是不會影響音質
推 : 有人實測一下有沒有差ㄇ 個人看到chart回穩反射性就覺得聲音好聽了6F 07/11 21:13
推 : 一整篇沒一段是看得懂的，該讓賢了8F 07/11 21:21
推 : Endpoint 的接收 buffer 估計也是 software buffer（RoonBridge 是至少 layer 3 的軟體）；software buffer 就會吃到 endpoint 的系統時鐘。9F 07/11 21:24
這個真的不重要
處理 Buffer 只要「來的及」，都不是問題
就像原文中也提到 Roon 網路是用 TCP 而不是一般串流常用的 UDP
所以就算封包出現錯誤也只要重傳就好（TCP 特性）
只要在 Buffer 耗盡前重傳成功，就不會出問題
推 : 緩衝區用完或爆滿是爆音和跳針嗎
無論如何，跟中原標準時間都沒關係啊12F 07/11 21:25
無論如何，跟中原標準時間都沒關係啊12F 07/11 21:25
#1aMUsw3K (Audiophile) [ptt.cc] Re: [閒聊] PC訊源雜訊解法
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 這類看到鬼的 為什麼會有問題，下面這個文件中已經指出來了
可以參考這篇的內容
然後就上面的回答
Roon 默認使用填充／刪除樣本，而非 Async SRC 來解決樣本多或少的狀況
推 : 我提議的對時對象是立即可用且免費的資源。如果@greg7575不想和NTP對時也無妨，只要在自己環境裡面選出一個參考時間就能達到一樣目的。
兩個端點時間同步，對於緩衝的使用率就能更有效率的掌握，也算幫助 Roon 所說的不完美那一塊。14F 07/11 21:36
兩個端點時間同步，對於緩衝的使用率就能更有效率的掌握，也算幫助 Roon 所說的不完美那一塊。14F 07/11 21:36
推 : 好喔。
我覺得這舉動沒意義啦，你覺得有意義很好啊
意思是這個舉動也許限縮到對roon有效而已對吧
對apple music的有效在哪？
擴大解釋到"以電腦為播放"會不會太舒服了19F 07/11 21:39
我覺得這舉動沒意義啦，你覺得有意義很好啊
意思是這個舉動也許限縮到對roon有效而已對吧
對apple music的有效在哪？
擴大解釋到"以電腦為播放"會不會太舒服了19F 07/11 21:39
推 : 我只是以白紙黑字的Roon拿來做example。另外我在我的原貼也提到macOS的Audio MIDI Setup也有對不同時鐘去re-sampling的機制，只要涉及到取樣率調整的運算，都和系統時間直接關係，希望您能理解。
我的提議不用錢，只要作業系統對時部分調整一下設定就好，也不需要這麼排斥。24F 07/11 21:49
我的提議不用錢，只要作業系統對時部分調整一下設定就好，也不需要這麼排斥。24F 07/11 21:49
Mac 的 Drift Correction 我上面貼的那篇也有提到
彌補的也只是 Audio device 間的 Audio clock 差異
跟 System clock 無關
就像這頁裏的第一個圖
https://support.apple.com/en-us/HT202000
Clock Source 能選系統時鐘嗎？只有 Audio device 能選不是嗎
→ : Buffer:當我塑膠？30F 07/11 21:51
推 : 我覺得不對的事我不做啊。我可以排斥吧。
不能持反對意見要先說啊
這篇發文貼了一大堆證明你錯了，還不能排斥喔31F 07/11 22:02
不能持反對意見要先說啊
這篇發文貼了一大堆證明你錯了，還不能排斥喔31F 07/11 22:02
推 : 請問我那邊有錯？請指正。34F 07/11 22:07
傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零，
因為 DAC 所做的所有操作都是從本地內存緩衝區播放。
這句是 Roon 的粗暴說法
推 : @oswyn 那個clock source selection只是為了系統時鐘resampling運算時的參考；發送的時候仍是軟體在發送。35F 07/11 22:09
不是，那個 Clock Source 是在選一台 Audio device 來當 Master Clock
其它 Audio device 的 Audio data 會依樣本數偏移來 ASRC
推 : 像EAC做offset的感覺，對同時播放錄音設備的檔案sync
跟中原標準時間真的完全沒關係，講到我都覺得煩37F 07/11 22:20
跟中原標準時間真的完全沒關係，講到我都覺得煩37F 07/11 22:20
![[圖]](https://i.imgur.com/5wIAjGK.jpg)
推 : 1. 建議看一下 AES67 規範（我是指 AES 文件商店購買的那份），針對介質使用 IEEE1588 作時鐘同步的規定。
2. 不知您有否用過 Audio MIDI Setup 堆積三到四個多聲道DAC的經驗？我蠻建議您實作一次，去觀察 drift correction 的動作。
我就次打住，直到您有答案為止。40F 07/11 22:26
2. 不知您有否用過 Audio MIDI Setup 堆積三到四個多聲道DAC的經驗？我蠻建議您實作一次，去觀察 drift correction 的動作。
我就次打住，直到您有答案為止。40F 07/11 22:26
不需要我的回答，人微言輕
建議您直接上 Roon community 發問
看 Brian | Roon Labs Founder 會有何回應
→ : 不要這麼壞好嗎46F 07/11 22:33
下次 Roon 改版就內建了
推 : 問題其實很簡單,覺得有差的一方測量DAC出來的訊號就好
有用對時工具出來的訊號和沒有用的訊號不一樣就能證明了如果有人認為這個量不到,那就請聽得出來的人蒙上眼,讓其他人隨機撥放,10次猜對9次也行,這樣做為的是排除"非聽覺性干擾47F 07/11 23:10
有用對時工具出來的訊號和沒有用的訊號不一樣就能證明了如果有人認為這個量不到,那就請聽得出來的人蒙上眼,讓其他人隨機撥放,10次猜對9次也行,這樣做為的是排除"非聽覺性干擾47F 07/11 23:10
盲測不科學啦
其實不用測，因為只要感覺對了就是對
有感這種東西是不需要實測跟量化的
推 : 我覺得讓電腦與NTP Server對時,是種樂趣,但音色沒有影響52F 07/11 23:21
推 : 弱弱的問 那是不是usb hub 只是改善了雜訊或5v 訊號沒有影響到dac53F 07/11 23:22
嗯，不好說
但數位厚...
推 : "有感"很有可能是"非聽覺性因素"影響阿55F 07/11 23:30
但有感了，當這個結果是事實
什麼原因造成還很重要嗎
就算是聽覺性因素影響，久了也會膩、麻痺、感情變淡想要換換啊
就像貼了個貼紙、還是點了個燈，看了就覺得好聽那就是有效投資
推 : O大文必推！56F 07/11 23:50
推 : 事實 難看就先被噴爛了57F 07/11 23:56
噓 : 原因是什麼怎麼不重要？不然搞科學是為了什麼？
安慰劑吃了也有感，吃安慰劑可以治病嗎？58F 07/12 00:21
安慰劑吃了也有感，吃安慰劑可以治病嗎？58F 07/12 00:21
這都能釣出些萌新
推 : 網內互打60F 07/12 00:31
→ : 聽個音響是要治病嗎...
最可能患得的大概是換換病吧61F 07/12 00:37
最可能患得的大概是換換病吧61F 07/12 00:37
推 : 專治換換病63F 07/12 00:47
推 : 換音響不如換老婆64F 07/12 00:49
旁邊坐個志玲姐姐用什麼聽都好聽
你說一切都是幻覺？實際上根本沒差？
沒錯、當然是幻覺
志玲姐姐怎麼可能坐在我家
推 : 我看是想咪兔65F 07/12 02:13
推 : 推 不過機翻還是比較難吃XD 還是原文舒服多了66F 07/12 05:56
推 : 覺得很煩啊，任何設備計算時間都是用晶振發出的訊號算用48MHz的就是累滿48M個抖動定義為一秒
晶振爛，對設備而言還是累滿48M個抖動為一秒
這個狀況下，可能48M個抖動跟實際的一秒就有差異
能顯示時間的程序會去抓48M個抖動來顯示時間的"一秒"
無論怎麼軟體校正，爛晶振抖出來的一秒就不是一秒
原原發文的一直覺得軟體校正就能讓爛晶振輸出準確一秒從他第一篇就講了，一直堅持他的"理論"。這有什麼辦法不過知識有盲區，我覺得很簡單的事不見得所有人能接受基本的觀念都錯了，身體本能的排斥很正常吧
至於DAC的緩衝就是DAC會從資料暫存庫裡拉貨出來
DAC看到音檔是44.1kHz的話就是拉這麼多出來播一秒
apple music暫存直接機八大的給你好幾GB來存
暫存裝的滿滿的就不用怕串流倉庫不夠播
foobar也能設暫存的量，不過很精細的說那是另一件事
反正原原po都說他就此打住了，我就這坨一次講完
就算你去抓中原標準時間回來，爛晶振還是堅持他的一秒你的電腦顯示的時間是一回事，爛晶振的抖動方式不會變第一篇我就舉LP的例子，你不求轉速穩定
而是覺得每15秒拉一下碟盤"校時"就好
殊不知這"校時"一點意義都沒有，轉速一樣不穩音樂照播如果你的"校時"有意義，那你的音樂要每15秒跳針一次
沒聽到跳針的話，表示校時跟dac的clock完全沒關係
在座各位有誰家的電腦按下校時，音樂會跳針的嗎？
戰過很多次了，數位出錯就會爆音。沒爆表示沒差啊
至於DPC Latency的問題不在這談，更煩
微軟拔拔在win11取消顯示秒數，cpu去主機板拉晶振算時間這件事就完美的解釋了電腦的一秒一秒是怎麼來的。
你能用軟體改造晶振的抖動次數，跟造物主同等級了
如同耳機板板友問的，cpu吃的clock從哪來呢？嘻嘻67F 07/12 07:08
晶振爛，對設備而言還是累滿48M個抖動為一秒
這個狀況下，可能48M個抖動跟實際的一秒就有差異
能顯示時間的程序會去抓48M個抖動來顯示時間的"一秒"
無論怎麼軟體校正，爛晶振抖出來的一秒就不是一秒
原原發文的一直覺得軟體校正就能讓爛晶振輸出準確一秒從他第一篇就講了，一直堅持他的"理論"。這有什麼辦法不過知識有盲區，我覺得很簡單的事不見得所有人能接受基本的觀念都錯了，身體本能的排斥很正常吧
至於DAC的緩衝就是DAC會從資料暫存庫裡拉貨出來
DAC看到音檔是44.1kHz的話就是拉這麼多出來播一秒
apple music暫存直接機八大的給你好幾GB來存
暫存裝的滿滿的就不用怕串流倉庫不夠播
foobar也能設暫存的量，不過很精細的說那是另一件事
反正原原po都說他就此打住了，我就這坨一次講完
就算你去抓中原標準時間回來，爛晶振還是堅持他的一秒你的電腦顯示的時間是一回事，爛晶振的抖動方式不會變第一篇我就舉LP的例子，你不求轉速穩定
而是覺得每15秒拉一下碟盤"校時"就好
殊不知這"校時"一點意義都沒有，轉速一樣不穩音樂照播如果你的"校時"有意義，那你的音樂要每15秒跳針一次
沒聽到跳針的話，表示校時跟dac的clock完全沒關係
在座各位有誰家的電腦按下校時，音樂會跳針的嗎？
戰過很多次了，數位出錯就會爆音。沒爆表示沒差啊
至於DPC Latency的問題不在這談，更煩
微軟拔拔在win11取消顯示秒數，cpu去主機板拉晶振算時間這件事就完美的解釋了電腦的一秒一秒是怎麼來的。
你能用軟體改造晶振的抖動次數，跟造物主同等級了
如同耳機板板友問的，cpu吃的clock從哪來呢？嘻嘻67F 07/12 07:08
推 : @greg7575 關於改系統時鐘會造成破音這件事，歡迎來我家坐坐，我demo給您看/聽。97F 07/12 09:45
→ : 事情很單純，就是serdes 原理而已，決定品質的就是DAC跟RX 本地clock性能，其他都只是暫存跟latency99F 07/12 10:18
這我過去也提過很多遍，聽我說不如聽專家說
但這也並不代表類比電氣特性不會透過介質串到其它設備就是了
不過有時就算專家說也無法憾動燒友不斷嘗試“改進”事物的信念
推 : 要確定是改進捏101F 07/12 10:43
有感就好捏
推 : 你進來了嗎? 我是說訊號102F 07/12 11:00
推 : 做任何事都會改變，而這個改變的原因不能亂講。
撐傘能遮陽，而不是撐傘把太陽變弱103F 07/12 11:22
撐傘能遮陽，而不是撐傘把太陽變弱103F 07/12 11:22
推 : @greg7575 來我家 我 demo 眼見耳聽為憑105F 07/12 11:33
聽了有感跟要佐證您的假設正確是不同的事
就像上面您提到 Drift Correction 跟系統時間有直接關係
說實作一次，去觀察 drift correction 的動作?
如何觀察到 Drift Correction 跟系統時間有直接關係？
是有什麼設備可以偵測還是反組譯看程式碼？或只是我感覺？
坦白說 Drift Correction 的運作原理網上很多資料，也沒什好辯的
實際上我也用過，但不再用的原因跟 Roon 上面的說法一樣
除非是後製商品賣錢，不然在 Replay 使用開銷太大得之過少不如放給它錯
If it can go wrong, it will.
但這個 Wrong 不太痛也很少發生
就放它很偶爾發生，而不是把沒問題的也全都整一遍
→ : 直接人工耳啊106F 07/12 11:38
推 : 對了 也歡迎 @Oswyn 來我家 我可以demo一些CLOCK_REALTIME 對音質的影響。邊操作邊解釋應該更容易溝通。107F 07/12 11:43
→ : 大家都能聽到109F 07/12 11:43
推 : 錄一段校時會爆音的上來瞧瞧，長知識110F 07/12 11:44
推 : 這種不影響就是進步的原動力啊。即使原因可能不是當初認為的那一個111F 07/12 11:49
→ : 那可以去拜讀一下量子力學113F 07/12 11:51
推 : 一邊講解一邊示範效果最大 我是真的希望G大和O大來我家家訪 無意引戰 而是把事實呈現給兩位會比在這裡文字描述有用的多114F 07/12 12:03
推 : 你高興就好
記得貼去roon論壇嘿。117F 07/12 12:15
記得貼去roon論壇嘿。117F 07/12 12:15
→ : 是否可以把引用跟自己意見區別明顯一點 不然一下翻譯一下自己論述 也可以用gpt把來源文章摘要 這樣會更棒119F 07/12 12:25
※ Reference Mark 還不夠清楚嗎:D
推 : G大不是積極的證明在下是錯的嗎？我同意您來家訪後，您來公布家訪細節，包含截圖、照片和對話（要錄音也行）。121F 07/12 12:30
Roon 原始討論串 system clock 只出現一次
而且後面 Roon 員工一直強調討論中的此 clock 非彼 clock
全文完全沒出現過 Data/Time 相關
依前後文這個 The system clock 也根本跟「真實時間」無關
要怎麼證明校時與音質有直接關聯應該不用家訪
因為就算家訪這兩者間的關聯還是無法以科學論述驗證啊
推 : 那…我去印紅布條 第一屆音響版版聚123F 07/12 12:35
推 : 所以我不去就是我講的都錯的意思嗎？
好喔那我不去，我俗辣，你對。
請繼續開發用軟體改變晶振的能力:)
我覺得我很友善了。嘻嘻124F 07/12 12:38
好喔那我不去，我俗辣，你對。
請繼續開發用軟體改變晶振的能力:)
我覺得我很友善了。嘻嘻124F 07/12 12:38
→ : 喔 明白了 看來ptt的格式 比較適合引用摘要 一大段真的不簡單 如果有QA以外的資料歡迎分享喔 不大想只看Roon的說法128F 07/12 12:44
我會建議有空要去看原文
推 : 晶振運作原理都講了，只想要輸贏。那你贏130F 07/12 12:47
推 : 支持家訪，最好可以作雙盲測試131F 07/12 12:51
推 : 說到對時後會不會跳針… 依據AES67 的文件，以 48KHz 來說，每 24.86 小時會 overflow，若把信號和時間在那時候對齊，是會跳針的。 https://i.imgur.com/MZcINCN.jpg
我一直以來都在講系統時間，晶振只是系統時間的參考信號，我不知道那邊溝通出問題？132F 07/12 12:52
我一直以來都在講系統時間，晶振只是系統時間的參考信號，我不知道那邊溝通出問題？132F 07/12 12:52
![[圖]](https://i.imgur.com/MZcINCNh.jpg)
我個人覺得最大的問題在
您看到 Roon 討論串中出現了 system clock 一次
就無限放大 system clock 的可能性
而沒通盤看完、與理解整個討論串中 Roon 試圖解釋的東西
推 : O大，您前個回覆，更讓我想把您奉為貴賓來接待，讓我仔細的和您解釋並示範吧。137F 07/12 12:57
推 : 多開幾個程式讓dpc latency牙起來。改變音質很簡單
不用牙到爆音的程度，負載重就很有感了。
尤其是nv的驅動，沒事做還可以牙起來
叫它做點事反而觸發降低latency。魔法驅動值五千
大師可以略過我，我在跟其它看戲的解釋可能的狀況139F 07/12 13:04
不用牙到爆音的程度，負載重就很有感了。
尤其是nv的驅動，沒事做還可以牙起來
叫它做點事反而觸發降低latency。魔法驅動值五千
大師可以略過我，我在跟其它看戲的解釋可能的狀況139F 07/12 13:04
→ : 也許只是因為一直對時 cpu進不去c-state144F 07/12 13:09
推 : cpu運作的鬆緊對音質影響也很大，樓上突破盲點
win11顯示秒數就不能休眠。cpu會一直牙145F 07/12 13:10
win11顯示秒數就不能休眠。cpu會一直牙145F 07/12 13:10
→ : 我覺得眾多燒友已經很極力 用人可以聽懂的語言去解釋了,還有談論的意義嗎
roon那篇原文 連機翻都講到可以如此白話147F 07/12 13:39
roon那篇原文 連機翻都講到可以如此白話147F 07/12 13:39
推 : 無法證明是校時改變音質還是校時軟體改變音質
任何程式要顯示秒都要叫cpu call晶振150F 07/12 13:46
任何程式要顯示秒都要叫cpu call晶振150F 07/12 13:46
基本上寫程式尤其低階 I/F、I/O，沒事不會去用到真實時間
都嗎讀計時器的 count 或用 10ns、100ms 這些相對時間
要知道現在幾點幾分幾秒需要更多換算
真實時間在電腦系統裏是拿來「給人看」的
推 : 惡靈古堡移植版的fps越高小刀傷害越高
程式喊了什麼要拆開來看才知道152F 07/12 14:04
程式喊了什麼要拆開來看才知道152F 07/12 14:04
推 : 支持樓主去家訪 都吵這麼兇了 不如家訪吧 親眼論證一下孰對孰錯再分享給大家確切結論154F 07/12 14:38
→ : 人工耳不是快速便捷 順便大家都能聽156F 07/12 14:48
推 : 家訪可以啊 先講好有甚麼儀器可以驗 不然也只是一起舒服157F 07/12 14:48
推 : 要看怎麼舒服法
幾個S
Siltech158F 07/12 14:49
幾個S
Siltech158F 07/12 14:49
→ : 幾個h
Harbeth161F 07/12 14:51
Harbeth161F 07/12 14:51
推 : 0.3 0.5 還是 1 我說線徑163F 07/12 14:53
→ : 錄音錄起來每次都不同 人工耳是想要用啥指標來看？164F 07/12 14:54
→ : 沒關係 因為差異性一致
至少要聽出有無變化即可 不求還原165F 07/12 14:56
至少要聽出有無變化即可 不求還原165F 07/12 14:56
推 : 發散也是差異 收斂也是差異 大膽假設 小心求證167F 07/12 15:13
推 : 我有個大膽的想法168F 07/12 15:15
→ : 快收起你大膽的想法169F 07/12 15:19
→ : 我有個大170F 07/12 15:29
推 : 大什麼大171F 07/12 15:36
→ : AES67是fully-synchronized system，沒有drift的問題，VAD只能做PTP Slave，VAD的音頻時鐘只能鎖定在PTP GM上，因為是burst形式的data，所以只要鎖定還在，音頻就沒問題，NTP不能加入鎖定，自然是沒有用的172F 07/12 16:08
→ : 我看過原文才問的 因為這只是Roon的說法 問題是原本的發文不是只適用RAAT 你們講的不完全一樣也 雞同鴨講了176F 07/12 16:13
這不是只是 Roon 的說法，只是 Roon 在相關討論中滿完整的梳理了一番
相關內容其實也在本版與友版中分散出現無數次
光我個人就提過很多次相關內容
只是 Roon 做為業界翹楚，說出來更有份量
推 : 原原po的討論口氣很客氣，我也相信他付出努力並無償分享完全出自好意，值得我這樣的路過鄉民給予感謝。但是即便認錯很困難，這還是值得追求的美德，因為您真的無法證明您做的改變對數位音樂播放有益，not@all.178F 07/12 16:14
推 : 對時就是種樂趣啦,無法改變音色的,但會增加server負擔(X)182F 07/12 16:25
→ : @sunyanwen VAD 是 PTP software slave，輸出的封包 time stamp 是來自系統時鐘。183F 07/12 16:35
→ : 不需要考慮timestamp的問題，所有設備都頻率鎖定在PTPGM上，playback的buffer+來自PTP GM的locked audio clock就可以保證絕對穩定的播放185F 07/12 16:51
→ : EPHY LPHY不是完整封包根本認不得，DAC 本體吃的都是re-sample PLL。當然noise injection 是另一回事要分開看188F 07/12 16:53
推 : https://i.imgur.com/5FzRNAS.jpg @sunyanwen 謝謝您的意見。或許是我看著 VAD audio clock 上上下下的不太舒服吧。其他器材只有 +-1ns 的變化。190F 07/12 17:06
![[圖]](https://i.imgur.com/5FzRNAS.jpg)
其實這些「很小的」時間波動，會被 Buffer cover
也就是 Roon 討論中提到的半滿 Buffer，既有庫存、也有空間
所以傳輸過程中的時鐘精度並不十分重要，只要 Buffer 配置得當
→ : 截圖是經過local NTP 對時後穩定的結果。若純以系統自動對時並處於 free clock 狀態的話，瞬時變化會 >100ns。AES67 標準 frame buffer 是 1ms。這樣的不穩定我個人認為有必要進一步管理。
補充：VAD 顯示的 audio clock 狀態即是 system clock
的狀態193F 07/12 17:31
補充：VAD 顯示的 audio clock 狀態即是 system clock
的狀態193F 07/12 17:31
AES67 有定義精度嗎？若有是多少？若無不就表示不是很重要嗎
1 ms 等於 1,000,000 ns
您是說 100ns 的變化會影響 1ms buffer 的穩定度？
我個人感覺就算是 100μs 都不太會
※ 編輯: Oswyn (114.36.215.60 臺灣), 07/12/2023 17:47:21
--