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

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“推”到其餘區域，利用從第一個區域恢復 的時鐘來控制速率。這是不可避免的，因為沒有辦法強制多個區域獨立時鐘源一致，因此 在這種情況下，我們需要使用如上所述的漂移補償技術。） Ｑ：，因為 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 來定位校正，因為周期性聲音更容易挑選出來。 我們一直在考慮將漂移調整轉移到服務器的想法，這可以允許更密集/更昂貴的技術，因 為我們有更多可用的 CPU 資源。還有一些願望可能支持跨不同技術的分組播放，這幾乎 肯定會引導我們朝這個方向發展，因為每個人的系統工作方式都有點不同。 Ｑ：因此，如果 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/ -- 我截出來的也是 Brian Luczkiewicz | Roon Labs Founder 跟另名員工所言 看完整串應該能理解，系統時鐘應該只跟維持 Buffer 吞吐有關 只要 Buffer 不欠載不溢出＆網路傳輸是正常的，是不會影響音質 這個真的不重要 處理 Buffer 只要「來的及」，都不是問題 就像原文中也提到 Roon 網路是用 TCP 而不是一般串流常用的 UDP 所以就算封包出現錯誤也只要重傳就好（TCP 特性） 只要在 Buffer 耗盡前重傳成功，就不會出問題 #1aMUsw3K (Audiophile) [ptt.cc] Re: [閒聊] PC訊源雜訊解法 https://www.ptt.cc/bbs/Audiophile/M.1683615162.A.0D4.html 可以參考這篇的內容 然後就上面的回答 Roon 默認使用填充／刪除樣本，而非 Async SRC 來解決樣本多或少的狀況 Mac 的 Drift Correction 我上面貼的那篇也有提到 彌補的也只是 Audio device 間的 Audio clock 差異 跟 System clock 無關 就像這頁裏的第一個圖 https://support.apple.com/en-us/HT202000 Clock Source 能選系統時鐘嗎？只有 Audio device 能選不是嗎 傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零， 因為 DAC 所做的所有操作都是從本地內存緩衝區播放。 這句是 Roon 的粗暴說法 不是，那個 Clock Source 是在選一台 Audio device 來當 Master Clock 其它 Audio device 的 Audio data 會依樣本數偏移來 ASRC 不需要我的回答，人微言輕 建議您直接上 Roon community 發問 看 Brian | Roon Labs Founder 會有何回應 下次 Roon 改版就內建了 盲測不科學啦 其實不用測，因為只要感覺對了就是對 有感這種東西是不需要實測跟量化的 嗯，不好說 但數位厚... 但有感了，當這個結果是事實 什麼原因造成還很重要嗎 就算是聽覺性因素影響，久了也會膩、麻痺、感情變淡想要換換啊 就像貼了個貼紙、還是點了個燈，看了就覺得好聽那就是有效投資 這都能釣出些萌新 旁邊坐個志玲姐姐用什麼聽都好聽 你說一切都是幻覺？實際上根本沒差？ 沒錯、當然是幻覺 志玲姐姐怎麼可能坐在我家 這我過去也提過很多遍，聽我說不如聽專家說 但這也並不代表類比電氣特性不會透過介質串到其它設備就是了 不過有時就算專家說也無法憾動燒友不斷嘗試“改進”事物的信念 有感就好捏 聽了有感跟要佐證您的假設正確是不同的事 就像上面您提到 Drift Correction 跟系統時間有直接關係 說實作一次，去觀察 drift correction 的動作? 如何觀察到 Drift Correction 跟系統時間有直接關係？ 是有什麼設備可以偵測還是反組譯看程式碼？或只是我感覺？ 坦白說 Drift Correction 的運作原理網上很多資料，也沒什好辯的 實際上我也用過，但不再用的原因跟 Roon 上面的說法一樣 除非是後製商品賣錢，不然在 Replay 使用開銷太大得之過少不如放給它錯 If it can go wrong, it will. 但這個 Wrong 不太痛也很少發生 就放它很偶爾發生，而不是把沒問題的也全都整一遍 ※ Reference Mark 還不夠清楚嗎:D Roon 原始討論串 system clock 只出現一次 而且後面 Roon 員工一直強調討論中的此 clock 非彼 clock 全文完全沒出現過 Data/Time 相關 依前後文這個 The system clock 也根本跟「真實時間」無關 要怎麼證明校時與音質有直接關聯應該不用家訪 因為就算家訪這兩者間的關聯還是無法以科學論述驗證啊 我會建議有空要去看原文 我個人覺得最大的問題在 您看到 Roon 討論串中出現了 system clock 一次 就無限放大 system clock 的可能性 而沒通盤看完、與理解整個討論串中 Roon 試圖解釋的東西 基本上寫程式尤其低階 I/F、I/O，沒事不會去用到真實時間 都嗎讀計時器的 count 或用 10ns、100ms 這些相對時間 要知道現在幾點幾分幾秒需要更多換算 真實時間在電腦系統裏是拿來「給人看」的 這不是只是 Roon 的說法，只是 Roon 在相關討論中滿完整的梳理了一番 相關內容其實也在本版與友版中分散出現無數次 光我個人就提過很多次相關內容 只是 Roon 做為業界翹楚，說出來更有份量 其實這些「很小的」時間波動，會被 Buffer cover 也就是 Roon 討論中提到的半滿 Buffer，既有庫存、也有空間 所以傳輸過程中的時鐘精度並不十分重要，只要 Buffer 配置得當 AES67 有定義精度嗎？若有是多少？若無不就表示不是很重要嗎 1 ms 等於 1,000,000 ns 您是說 100ns 的變化會影響 1ms buffer 的穩定度？ 我個人感覺就算是 100μs 都不太會 但很不幸的是，人耳對時間差並不太靈敏 就像一般評延遲感知是用 10ms，超過明顯能感到有延遲 部分人比較敏感的也不過幾 ms，幾 μs 是不可能更別說到 ns 的差異 就像一個 20 kHz 的聲波走的的時間是 0.05ms or 50μs 人耳分析頻率無法太精細，有點像 FFT 是以一段時間開窗分析窗內的所有頻率 所以幾 ms 內的聲音是分不出前後差異的 數位電子電路的時間，是用晶振振動次數 count 計數出來的.... 沒有晶振，沒有時間，連 CPU 都不會動了 是，因為時間是用晶振算出來的 就像 Roon 的回應，不是不需要時間，而是時間沒這麼關鍵到精度幾 μs DAC 外的任何時鐘的品質，不需要過度擔心 關鍵確實是一個正常運行的網絡環境 就像 Roon 所說的拿去用在 DAC ，適材適所 晶振是系統時鐘的機心，一體兩面 以數位電子與程式設計的觀點，系統時鐘＝晶振＋計數器 校時程式能做的除對時外，是重新計算時間單位需要多少計數 但依 Roon 討論串這段的時間精度並不需要太過計較 另外回到 e大的想法，我會切成兩個獨立議題 一個是一般家用戶，尤其是沒有多區域同步播放需求及AES67 or Dante 多聲道 這個校時無關緊要 有多區域同步播放、AES67 or Dante 多聲道我不熟 但依上面 s大的回應，Protocol 應該有解決同步問題 不需要額外的處理才是 過去 e大的發文中我好像也回應過 AES67、Dante 是很難走入一般家庭中的 一般家庭中就算是透過區網串流，也沒什麼人會碰到需要同步的問題 因為音樂就你丟我收，收到就放 最多 AV 嘴型同步，但這也跟系統時間不太有直接連接 異步，就是各自為政，在規範內照自己的步調走 AD/DA 同時有的狀況，一般是在專業錄音或現場直播 可有主時鐘、或 Drift Correction、或用放刪除插入等策略，看選擇
※ 批踢踢實業坊(ptt.cc), 來自: 114.36.215.60 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689079757.A.F41.html

推 elguapo: 我不知道您能否接受我截圖給您的內容，那個是 Roon 創 07/11 21:11

→ elguapo: 辦人寫的。Roon 會綜合 endpoint 回傳的時鐘資料，去比 07/11 21:11

→ elguapo: 對 Roon 本身的系統時鐘的差別，然後建立一個預測模型 07/11 21:11

→ elguapo: ，用這個模型去送信號。這時系統時鐘主宰信號發送，畢 07/11 21:11

→ elguapo: 竟這時的控制權是 Roon，不是 DAC。 07/11 21:11

推 qo3650: 有人實測一下有沒有差ㄇ 個人看到chart回穩反射性就覺得聲 07/11 21:13

→ qo3650: 音好聽了 07/11 21:13

推 greg7575: 一整篇沒一段是看得懂的，該讓賢了 07/11 21:21

推 elguapo: Endpoint 的接收 buffer 估計也是 software buffer（Roon 07/11 21:24

→ elguapo: Bridge 是至少 layer 3 的軟體）；software buffer 就會 07/11 21:24

→ elguapo: 吃到 endpoint 的系統時鐘。 07/11 21:24

推 greg7575: 緩衝區用完或爆滿是爆音和跳針嗎 07/11 21:25

→ greg7575: 無論如何，跟中原標準時間都沒關係啊 07/11 21:25

推 elguapo: 我提議的對時對象是立即可用且免費的資源。如果@greg7575 07/11 21:36

→ elguapo: 不想和NTP對時也無妨，只要在自己環境裡面選出一個參考 07/11 21:36

→ elguapo: 時間就能達到一樣目的。 07/11 21:36

推 elguapo: 兩個端點時間同步，對於緩衝的使用率就能更有效率的掌握 07/11 21:38

→ elguapo: ，也算幫助 Roon 所說的不完美那一塊。 07/11 21:38

推 greg7575: 好喔。 07/11 21:39

推 greg7575: 我覺得這舉動沒意義啦，你覺得有意義很好啊 07/11 21:40

→ greg7575: 意思是這個舉動也許限縮到對roon有效而已對吧 07/11 21:43

→ greg7575: 對apple music的有效在哪？ 07/11 21:44

→ greg7575: 擴大解釋到"以電腦為播放"會不會太舒服了 07/11 21:45

推 elguapo: 我只是以白紙黑字的Roon拿來做example。另外我在我的原貼 07/11 21:49

→ elguapo: 也提到macOS的Audio MIDI Setup也有對不同時鐘去re-sampl 07/11 21:49

→ elguapo: ing的機制，只要涉及到取樣率調整的運算，都和系統時間 07/11 21:49

→ elguapo: 直接關係，希望您能理解。 07/11 21:49

→ elguapo: 我的提議不用錢，只要作業系統對時部分調整一下設定就好 07/11 21:51

→ elguapo: ，也不需要這麼排斥。 07/11 21:51

→ m9172250: Buffer:當我塑膠？ 07/11 21:51

推 greg7575: 我覺得不對的事我不做啊。我可以排斥吧。 07/11 22:02

→ greg7575: 不能持反對意見要先說啊 07/11 22:03

→ greg7575: 這篇發文貼了一大堆證明你錯了，還不能排斥喔 07/11 22:04

推 elguapo: 請問我那邊有錯？請指正。 07/11 22:07

推 elguapo: @oswyn 那個clock source selection只是為了系統時鐘resa 07/11 22:09

→ elguapo: mpling運算時的參考；發送的時候仍是軟體在發送。 07/11 22:09

推 greg7575: 像EAC做offset的感覺，對同時播放錄音設備的檔案sync 07/11 22:20

→ greg7575: 跟中原標準時間真的完全沒關係，講到我都覺得煩 07/11 22:21

→ m9172250: http://i.imgur.com/5wIAjGK.jpg 07/11 22:23

推 elguapo: 1. 建議看一下 AES67 規範（我是指 AES 文件商店購買的 07/11 22:26

→ elguapo: 那份），針對介質使用 IEEE1588 作時鐘同步的規定。 07/11 22:26

→ elguapo: 2. 不知您有否用過 Audio MIDI Setup 堆積三到四個多聲道 07/11 22:26

→ elguapo: DAC的經驗？我蠻建議您實作一次，去觀察 drift correctio 07/11 22:26

→ elguapo: n 的動作。 07/11 22:26

→ elguapo: 我就次打住，直到您有答案為止。 07/11 22:26

→ m9172250: 不要這麼壞好嗎 07/11 22:33

推 chiyoda: 問題其實很簡單,覺得有差的一方測量DAC出來的訊號就好 07/11 23:10

→ chiyoda: 有用對時工具出來的訊號和沒有用的訊號不一樣就能證明了 07/11 23:11

→ chiyoda: 如果有人認為這個量不到,那就請聽得出來的人蒙上眼,讓其 07/11 23:12

→ chiyoda: 他人隨機撥放,10次猜對9次也行,這樣做為的是排除"非聽覺 07/11 23:14

→ chiyoda: 性干擾 07/11 23:14

推 tienam: 我覺得讓電腦與NTP Server對時,是種樂趣,但音色沒有影響 07/11 23:21

推 dancehotdog: 弱弱的問 那是不是usb hub 只是改善了雜訊或5v 訊號 07/11 23:22

→ dancehotdog: 沒有影響到dac 07/11 23:22

推 chiyoda: "有感"很有可能是"非聽覺性因素"影響阿 07/11 23:30

推 djboy: O大文必推！ 07/11 23:50

推 yys310: 事實 難看就先被噴爛了 07/11 23:56

噓 stupidHNG: 原因是什麼怎麼不重要？不然搞科學是為了什麼？ 07/12 00:21

→ stupidHNG: 安慰劑吃了也有感，吃安慰劑可以治病嗎？ 07/12 00:22

推 icekiba: 網內互打 07/12 00:31

→ broskwlin: 聽個音響是要治病嗎... 07/12 00:37

→ broskwlin: 最可能患得的大概是換換病吧 07/12 00:38

推 yys310: 專治換換病 07/12 00:47

推 icekiba: 換音響不如換老婆 07/12 00:49

推 icekiba: 我看是想咪兔 07/12 02:13

推 comipa: 推 不過機翻還是比較難吃XD 還是原文舒服多了 07/12 05:56

推 greg7575: 覺得很煩啊，任何設備計算時間都是用晶振發出的訊號算 07/12 07:08

→ greg7575: 用48MHz的就是累滿48M個抖動定義為一秒 07/12 07:09

→ greg7575: 晶振爛，對設備而言還是累滿48M個抖動為一秒 07/12 07:10

→ greg7575: 這個狀況下，可能48M個抖動跟實際的一秒就有差異 07/12 07:10

→ greg7575: 能顯示時間的程序會去抓48M個抖動來顯示時間的"一秒" 07/12 07:11

→ greg7575: 無論怎麼軟體校正，爛晶振抖出來的一秒就不是一秒 07/12 07:12

→ greg7575: 原原發文的一直覺得軟體校正就能讓爛晶振輸出準確一秒 07/12 07:13

→ greg7575: 從他第一篇就講了，一直堅持他的"理論"。這有什麼辦法 07/12 07:13

→ greg7575: 不過知識有盲區，我覺得很簡單的事不見得所有人能接受 07/12 07:14

推 greg7575: 基本的觀念都錯了，身體本能的排斥很正常吧 07/12 07:17

推 greg7575: 至於DAC的緩衝就是DAC會從資料暫存庫裡拉貨出來 07/12 07:21

→ greg7575: DAC看到音檔是44.1kHz的話就是拉這麼多出來播一秒 07/12 07:23

→ greg7575: apple music暫存直接機八大的給你好幾GB來存 07/12 07:23

→ greg7575: 暫存裝的滿滿的就不用怕串流倉庫不夠播 07/12 07:24

→ greg7575: foobar也能設暫存的量，不過很精細的說那是另一件事 07/12 07:25

→ greg7575: 反正原原po都說他就此打住了，我就這坨一次講完 07/12 07:26

推 greg7575: 就算你去抓中原標準時間回來，爛晶振還是堅持他的一秒 07/12 07:28

→ greg7575: 你的電腦顯示的時間是一回事，爛晶振的抖動方式不會變 07/12 07:29

推 greg7575: 第一篇我就舉LP的例子，你不求轉速穩定 07/12 07:31

→ greg7575: 而是覺得每15秒拉一下碟盤"校時"就好 07/12 07:32

→ greg7575: 殊不知這"校時"一點意義都沒有，轉速一樣不穩音樂照播 07/12 07:33

→ greg7575: 如果你的"校時"有意義，那你的音樂要每15秒跳針一次 07/12 07:33

→ greg7575: 沒聽到跳針的話，表示校時跟dac的clock完全沒關係 07/12 07:34

→ greg7575: 在座各位有誰家的電腦按下校時，音樂會跳針的嗎？ 07/12 07:35

推 greg7575: 戰過很多次了，數位出錯就會爆音。沒爆表示沒差啊 07/12 07:48

→ greg7575: 至於DPC Latency的問題不在這談，更煩 07/12 07:49

推 greg7575: 微軟拔拔在win11取消顯示秒數，cpu去主機板拉晶振算時間 07/12 08:24

→ greg7575: 這件事就完美的解釋了電腦的一秒一秒是怎麼來的。 07/12 08:25

→ greg7575: 你能用軟體改造晶振的抖動次數，跟造物主同等級了 07/12 08:25

推 greg7575: 如同耳機板板友問的，cpu吃的clock從哪來呢？嘻嘻 07/12 08:28

推 elguapo: @greg7575 關於改系統時鐘會造成破音這件事，歡迎來我家 07/12 09:45

→ elguapo: 坐坐，我demo給您看/聽。 07/12 09:45

→ bt092001: 事情很單純，就是serdes 原理而已，決定品質的就是DAC 07/12 10:18

→ bt092001: 跟RX 本地clock性能，其他都只是暫存跟latency 07/12 10:18

推 icekiba: 要確定是改進捏 07/12 10:43

推 icekiba: 你進來了嗎? 我是說訊號 07/12 11:00

推 greg7575: 做任何事都會改變，而這個改變的原因不能亂講。 07/12 11:22

推 greg7575: 撐傘能遮陽，而不是撐傘把太陽變弱 07/12 11:24

推 elguapo: @greg7575 來我家 我 demo 眼見耳聽為憑 07/12 11:33

→ m9172250: 直接人工耳啊 07/12 11:38

推 elguapo: 對了 也歡迎 @Oswyn 來我家 我可以demo一些CLOCK_REALTIM 07/12 11:43

→ elguapo: E 對音質的影響。邊操作邊解釋應該更容易溝通。 07/12 11:43

→ m9172250: 大家都能聽到 07/12 11:43

推 greg7575: 錄一段校時會爆音的上來瞧瞧，長知識 07/12 11:44

推 jakkx: 這種不影響就是進步的原動力啊。即使原因可能不是當初認為 07/12 11:49

→ jakkx: 的那一個 07/12 11:49

→ m9172250: 那可以去拜讀一下量子力學 07/12 11:51

推 elguapo: 一邊講解一邊示範效果最大 我是真的希望G大和O大來我家家 07/12 12:03

→ elguapo: 訪 無意引戰 而是把事實呈現給兩位會比在這裡文字描述有 07/12 12:03

→ elguapo: 用的多 07/12 12:03

推 greg7575: 你高興就好 07/12 12:15

推 greg7575: 記得貼去roon論壇嘿。 07/12 12:20

→ lacer: 是否可以把引用跟自己意見區別明顯一點 不然一下翻譯一下自 07/12 12:25

→ lacer: 己論述 也可以用gpt把來源文章摘要 這樣會更棒 07/12 12:25

推 elguapo: G大不是積極的證明在下是錯的嗎？我同意您來家訪後，您 07/12 12:30

→ elguapo: 來公布家訪細節，包含截圖、照片和對話（要錄音也行）。 07/12 12:30

推 icekiba: 那…我去印紅布條 第一屆音響版版聚 07/12 12:35

推 greg7575: 所以我不去就是我講的都錯的意思嗎？ 07/12 12:38

→ greg7575: 好喔那我不去，我俗辣，你對。 07/12 12:38

→ greg7575: 請繼續開發用軟體改變晶振的能力:) 07/12 12:40

→ greg7575: 我覺得我很友善了。嘻嘻 07/12 12:42

→ lacer: 喔 明白了 看來ptt的格式 比較適合引用摘要 一大段真的不簡 07/12 12:44

→ lacer: 單 如果有QA以外的資料歡迎分享喔 不大想只看Roon的說法 07/12 12:44

推 greg7575: 晶振運作原理都講了，只想要輸贏。那你贏 07/12 12:47

推 jwchen119: 支持家訪，最好可以作雙盲測試 07/12 12:51

推 elguapo: 說到對時後會不會跳針… 依據AES67 的文件，以 48KHz 來 07/12 12:52

→ elguapo: 說，每 24.86 小時會 overflow，若把信號和時間在那時候 07/12 12:52

→ elguapo: 對齊，是會跳針的。 https://i.imgur.com/MZcINCN.jpg 07/12 12:52

→ elguapo: 我一直以來都在講系統時間，晶振只是系統時間的參考信號 07/12 12:53

→ elguapo: ，我不知道那邊溝通出問題？ 07/12 12:53

推 elguapo: O大，您前個回覆，更讓我想把您奉為貴賓來接待，讓我仔 07/12 12:57

→ elguapo: 細的和您解釋並示範吧。 07/12 12:57

推 greg7575: 多開幾個程式讓dpc latency牙起來。改變音質很簡單 07/12 13:04

→ greg7575: 不用牙到爆音的程度，負載重就很有感了。 07/12 13:04

→ greg7575: 尤其是nv的驅動，沒事做還可以牙起來 07/12 13:05

→ greg7575: 叫它做點事反而觸發降低latency。魔法驅動值五千 07/12 13:05

→ greg7575: 大師可以略過我，我在跟其它看戲的解釋可能的狀況 07/12 13:06

→ comipa: 也許只是因為一直對時 cpu進不去c-state 07/12 13:09

推 greg7575: cpu運作的鬆緊對音質影響也很大，樓上突破盲點 07/12 13:10

→ greg7575: win11顯示秒數就不能休眠。cpu會一直牙 07/12 13:11

→ m9172250: 我覺得眾多燒友已經很極力 用人可以聽懂的語言去解釋了, 07/12 13:39

→ m9172250: 還有談論的意義嗎 07/12 13:39

→ m9172250: roon那篇原文 連機翻都講到可以如此白話 07/12 13:43

推 greg7575: 無法證明是校時改變音質還是校時軟體改變音質 07/12 13:46

推 greg7575: 任何程式要顯示秒都要叫cpu call晶振 07/12 13:49

推 greg7575: 惡靈古堡移植版的fps越高小刀傷害越高 07/12 14:04

→ greg7575: 程式喊了什麼要拆開來看才知道 07/12 14:05

推 Zyar: 支持樓主去家訪 都吵這麼兇了 不如家訪吧 親眼論證一下孰對 07/12 14:38

→ Zyar: 孰錯再分享給大家確切結論 07/12 14:38

→ m9172250: 人工耳不是快速便捷 順便大家都能聽 07/12 14:48

推 chibob: 家訪可以啊 先講好有甚麼儀器可以驗 不然也只是一起舒服 07/12 14:48

推 icekiba: 要看怎麼舒服法 07/12 14:49

推 icekiba: 幾個S 07/12 14:49

推 icekiba: Siltech 07/12 14:49

→ m9172250: 幾個h 07/12 14:51

→ m9172250: Harbeth 07/12 14:51

推 icekiba: 0.3 0.5 還是 1 我說線徑 07/12 14:53

→ yys310: 錄音錄起來每次都不同 人工耳是想要用啥指標來看？ 07/12 14:54

→ m9172250: 沒關係 因為差異性一致 07/12 14:56

→ m9172250: 至少要聽出有無變化即可 不求還原 07/12 14:56

推 chibob: 發散也是差異 收斂也是差異 大膽假設 小心求證 07/12 15:13

推 icekiba: 我有個大膽的想法 07/12 15:15

→ chibob: 快收起你大膽的想法 07/12 15:19

→ m9172250: 我有個大 07/12 15:29

推 icekiba: 大什麼大 07/12 15:36

→ sunyanwen: AES67是fully-synchronized system，沒有drift的問題， 07/12 16:08

→ sunyanwen: VAD只能做PTP Slave，VAD的音頻時鐘只能鎖定在PTP GM上 07/12 16:08

→ sunyanwen: ，因為是burst形式的data，所以只要鎖定還在，音頻就沒 07/12 16:08

→ sunyanwen: 問題，NTP不能加入鎖定，自然是沒有用的 07/12 16:08

→ lacer: 我看過原文才問的 因為這只是Roon的說法 問題是原本的發文 07/12 16:13

→ lacer: 不是只適用RAAT 你們講的不完全一樣也 雞同鴨講了 07/12 16:13

推 max0427: 原原po的討論口氣很客氣，我也相信他付出努力並無償分享 07/12 16:14

→ max0427: 完全出自好意，值得我這樣的路過鄉民給予感謝。但是即便 07/12 16:14

→ max0427: 認錯很困難，這還是值得追求的美德，因為您真的無法證明 07/12 16:14

→ max0427: 您做的改變對數位音樂播放有益，[email protected]. 07/12 16:14

推 tienam: 對時就是種樂趣啦,無法改變音色的,但會增加server負擔(X) 07/12 16:25

→ elguapo: @sunyanwen VAD 是 PTP software slave，輸出的封包 time 07/12 16:35

→ elguapo: stamp 是來自系統時鐘。 07/12 16:36

→ sunyanwen: 不需要考慮timestamp的問題，所有設備都頻率鎖定在PTP 07/12 16:51

→ sunyanwen: GM上，playback的buffer+來自PTP GM的locked audio cl 07/12 16:51

→ sunyanwen: ock就可以保證絕對穩定的播放 07/12 16:51

→ bt092001: EPHY LPHY不是完整封包根本認不得，DAC 本體吃的都是re- 07/12 16:53

→ bt092001: sample PLL。當然noise injection 是另一回事要分開看 07/12 16:53

推 elguapo: https://i.imgur.com/5FzRNAS.jpg @sunyanwen 謝謝您的 07/12 17:06

→ elguapo: 意見。或許是我看著 VAD audio clock 上上下下的不太舒服 07/12 17:06

→ elguapo: 吧。其他器材只有 +-1ns 的變化。 07/12 17:06

→ elguapo: 截圖是經過local NTP 對時後穩定的結果。若純以系統自動 07/12 17:31

→ elguapo: 對時並處於 free clock 狀態的話，瞬時變化會 >100ns。AE 07/12 17:31

→ elguapo: S67 標準 frame buffer 是 1ms。這樣的不穩定我個人認為 07/12 17:31

→ elguapo: 有必要進一步管理。 07/12 17:31

→ elguapo: 補充：VAD 顯示的 audio clock 狀態即是 system clock 07/12 17:33

→ elguapo: 的狀態 07/12 17:33

推 tienam: win11 KB5028185更新,啟用moment 3,工作列讀秒功能回歸. 07/13 00:44

→ tienam: 可以設定工作列讀秒功能,讓CPU不要沉睡. 07/13 00:45

推 Myt33: macOS裝caffeine會不會也有類似的效果？ 07/13 00:52

推 elguapo: 1. AES67 精度規範沿用 AES11 07/13 08:34

→ elguapo: 2. DXD 352800 samples per second，sample 與 sample 07/13 08:34

→ elguapo: 間隔約 2.83us，用這個間隔看 100ns 的 jitter 又會是多 07/13 08:34

→ elguapo: 大的影響？這只是單一聲道，若為12聲道DXD？ 07/13 08:34

推 greg7575: sample跟sample之間沒有間隔。是晶振幫忙決定 07/13 09:07

→ greg7575: 晶振誤差的時基抖動 07/13 09:08

→ greg7575: 有空我會來留幾個字 07/13 09:08

推 greg7575: 晶振的精度決定一切，不是你一直講的中原標準時間。 07/13 09:12

推 greg7575: 心跳決定你是人以及行為，而不是西元民國 07/13 09:30

→ elguapo: A 電腦用 AES67 傳音訊給 B 電腦，請問晶振在哪裡？ 07/13 11:04

→ elguapo: A電腦用Dante傳音訊給B電腦，B電腦再用Ravenna傳給C電腦 07/13 11:55

→ elguapo: ，請問晶振又在哪裡？時鐘要依據誰？ 07/13 11:55

推 greg7575: 經過這幾天的討論，是依據你的感覺。 07/13 11:59

→ elguapo: A 電腦 macOS 跑 NAA 守護程式當作 B 電腦的 HQPlayer in 07/13 12:00

→ elguapo: put，請問晶振在哪裡？時鐘又是誰為主？ 07/13 12:00

→ greg7575: 晶振造時間的本質我講再多次也無法改變你的感覺 07/13 12:00

→ greg7575: 發給外國人教育他們，我是不受教啦。 07/13 12:02

→ greg7575: 晶振在主機板上面，你把它拔了試試能不能開機 07/13 12:02

→ greg7575: 反正你說會依靠源頭時鐘嘛 07/13 12:03

→ greg7575: 留下你覺得有用的那個晶振，其它全拔了齁 07/13 12:03

→ elguapo: 以上三種狀況開大buffer確實就能解決問題，但若環境要求 07/13 12:04

→ elguapo: 要越即時越好，那麼你會怎麼做？ 07/13 12:04

→ elguapo: 電腦主機板的晶振管音訊samples的發送？ 07/13 12:06

推 greg7575: 拔掉啊，你都說晶振沒用。 07/13 12:06

→ m9172250: buffer:很趕嗎 07/13 12:07

→ elguapo: 我只問那三個場景你所謂的晶振在哪裡。你一直說這音訊資 07/13 12:09

→ elguapo: 料是晶振處理就好？ 07/13 12:09

推 greg7575: 那剪掉嘛。尖嘴鉗能搞定的事，找我輸贏幹嘛 07/13 12:14

→ greg7575: 講晶振處理這幾個字就表示你啥也不懂 07/13 12:15

→ greg7575: 音樂檔像一坨文字稿，依讀稿機的速度輸出 07/13 12:17

→ greg7575: 這坨文字無論你用掛號的還是email的都不影響讀稿機 07/13 12:17

→ greg7575: 你的堅持讓我舉例舉到我都快沒想法了 07/13 12:18

→ elguapo: 因為我認為您應該是學有專精，有我不足的知識，來求教的 07/13 12:20

→ elguapo: ，謝謝。 07/13 12:20

推 greg7575: 文字稿本身沒有時間，內容傳輸只要保證正確就好 07/13 12:20

→ greg7575: 你看我沒有很正常啊，我都舉凡人的例子 07/13 12:20

→ greg7575: 不用太抬舉我。嘻嘻 07/13 12:20

→ elguapo: O 大您的回文不就寫了「時間」？ 07/13 12:21

推 greg7575: 人家的時間不是你的中原標準時間 07/13 12:24

→ greg7575: 我會保持隨時出來廢話，你要忍耐 07/13 12:24

推 m9172250: http://i.imgur.com/3tUQk1P.jpg 07/13 12:27

→ m9172250: 這是守序中立的晶振 07/13 12:27

推 greg7575: 是不是有人以為晶振裡有小精靈，可以用軟體調整啊 07/13 12:30

→ elguapo: VCXO：當我塑膠 07/13 12:33

推 greg7575: 你已經調出ns級的正確，去笑那些晶振廠啊 07/13 12:36

→ greg7575: 自信這種東西用循環論證可以膨脹很快 07/13 12:37

推 greg7575: 你的校時軟體可以修正晶振的誤差，泰褲啦 07/13 12:39

→ elguapo: 留言怎麼會有情緒性反應？是因為我的問題太簡單而損人尊 07/13 12:50

→ elguapo: 嚴嗎？ 07/13 12:50

推 greg7575: 你是不是查了晶振原理之後大徹大悟了 07/13 12:55

→ greg7575: 我句句都在引導你考查真相啊 07/13 12:57

→ greg7575: 你的校時軟體能改變晶振嗎？快回答我 07/13 12:57

推 greg7575: 有問題就問，大家回答。耳機板那邊你也去看看 07/13 13:03

→ elguapo: 我從頭是一直在講「系統時鐘」，是閣下一直在扯晶振，請 07/13 13:08

→ elguapo: 勿不當連結。 07/13 13:08

推 greg7575: 可惜我以為你大徹大悟了 07/13 13:26

推 greg7575: 無法用任何校時去改晶振。改顯示時間只是改爽的而已 07/13 13:31

推 greg7575: 偏偏我見識少只能舉通俗的例子。 07/13 13:58

→ greg7575: 讀稿機不會因為晚一兩秒開始唸而改變內容 07/13 13:59

→ greg7575: 語速也不會改變內容，只會改變聽感。 07/13 14:00

→ elguapo: 我誠心邀請O大來我家坐坐，我必奉為上賓，分享同步乙太 07/13 14:00

→ elguapo: 網路和AoIP的一些實作以及performance optimization方法 07/13 14:00

→ elguapo: ，並實作可重複呈現的收系統時鐘影響的音質變化（這真的 07/13 14:00

→ elguapo: 不用AB test，幾個簡單指令現象就會發生）；也或許我的me 07/13 14:00

→ elguapo: thodology有問題，也歡迎指正我的問題盲點。我也同意由您 07/13 14:00

→ elguapo: 來貼家訪後的文章，把您所見所聞都寫出來（包含照片、錄 07/13 14:00

→ elguapo: 音等）。 07/13 14:00

→ greg7575: 追求聽感是計較語速還是計較幾點幾分開始唸呢？ 07/13 14:00

→ greg7575: 他前面就說過了，有改變也不能證明你的理論是對的。 07/13 14:01

→ greg7575: 你的盲點這幾天大家講很清楚而你堅持只要見面輸贏。 07/13 14:01

→ greg7575: 至於你認為我沒學識只會搗亂，我欣然接受。 07/13 14:02

→ elguapo: 因為我講的這些現象要一邊講一邊做才好溝通，為什麼會有 07/13 14:15

→ elguapo: 見面輸贏的錯覺？ 07/13 14:15

→ m9172250: cpu:好啦 我有在做事 不要再敲我了 07/13 14:30

推 greg7575: 原理以及思辯方式都講這麼清楚，還能有什麼嗎？ 07/13 14:45

→ greg7575: 從一開始就沒否定你的行為會影響音質 07/13 14:45

→ greg7575: 我否定的是你對於你的行為的解釋 07/13 14:45

→ greg7575: 有認同你的解釋的人麻煩也出個聲 07/13 14:46

→ m9172250: 既然有差 要表現出來 不能人工耳錄一綠直接丟出來嗎 07/13 14:46

→ greg7575: 不要以為是引戰還是霸凌，我一直想幫你。 07/13 14:46

推 greg7575: 裝忙的cpu程式在耳機板也有人貼 07/13 14:49

推 greg7575: 你的第一篇的立論建立在校時軟體能改變晶振 07/13 15:02

→ greg7575: 這個立論錯誤，後面都不用提。 07/13 15:03

推 greg7575: 找誰家訪都不能改變這個錯誤立論 07/13 15:07

→ elguapo: 請問我文章哪一段敘述是要改變晶振？ 07/13 15:09

→ greg7575: 依有學過計算機原理的人都知道，時基由晶振決定 07/13 15:10

→ greg7575: 你能用校時軟體改變時基，這就是你的超能力 07/13 15:10

→ greg7575: 也許因為你沒有這個觀念才會有這麼多事。 07/13 15:11

→ greg7575: 沒有觀念學就有了，不是什麼人格品德的批評 07/13 15:12

推 greg7575: https://i.imgur.com/LlT6dRK.jpg 07/13 15:16

推 kshieh: 校時對AoIP timestamp sync來說是極為重要的「必要之惡」 07/13 15:17

→ kshieh: 。而這裡99%的版友都是用實體訊號線(同軸/光纖/HDMI)直連 07/13 15:17

→ kshieh: ，完全不需要擔心這個因素，也難怪原原po會找不到知音 07/13 15:17

→ greg7575: https://i.imgur.com/eBUXCAj.jpg 07/13 15:17

→ greg7575: 找chatgpt家訪，告訴他你的重大發現 07/13 15:17

→ elguapo: 我只問我的原貼哪一句話在說對時是改變晶振，結果你拿cha 07/13 15:21

→ elguapo: tGPT? 07/13 15:21

推 greg7575: 不然你說說你對於電腦的時間定義好嗎？ 07/13 15:25

→ greg7575: 如何在電腦上產生一秒。什麼是時間什麼是時鐘 07/13 15:26

→ greg7575: 請你大方的分享你的定義。謝謝你。越詳細越好 07/13 15:26

推 greg7575: 你的校時軟體能均勻時間就表示你能改變晶振呀 07/13 15:42

→ elguapo: 請摘出我原貼裡面，閣下認為我有表示是用對時工具改變晶 07/13 15:43

→ elguapo: 振的任何文字。有就截圖貼出來，沒有就說沒有。 07/13 15:43

推 icekiba: Steins;Gate 先從香蕉開始吧 07/13 15:45

→ elguapo: 對時是對 CLOCK_REALTIME 校正，您該不會不知道什麼是 CL 07/13 15:48

→ elguapo: OCK_REALTIME 吧？ 07/13 15:48

推 greg7575: 好啦你對。我人生不會再跟你起爭議。我保證 07/13 16:45

推 shaylin3: 現在聽個音樂,知識量要這麼豐富了嗎 07/13 16:48

推 icekiba: 一直都是 07/13 16:52

推 downlevel99: 沒有一個字看得懂的 我覺得可以退坑了 07/13 18:59

推 lee28119: 整串看完的結論是沒有同步需求就不用掛主時鐘 靠AD/DA 07/14 09:46

→ lee28119: 的時鐘就夠了這樣嗎？ 07/14 09:46