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

作者: Oswyn (Oswyn)   2023-07-11 20:49:13
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 要支援「網路多區域播放」,因為有多個設備所以數據傳輸管理才更複雜
Q:因為聽起來我們不需要過度擔心除 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 相關討論串中也提過
Q:因此,如果 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信號才能實現其全部性能,那麼設備設計人
員真的完成了工作嗎?

Q:這好像是@加斯曼的問題仍然沒有答案,除非已經給出的答案相當於:“也許,但前提是
這些輔助設備允許 Roon 訪問修改後的/新的 DAC 時鐘信號。” 這是一個公平的總結嗎@
布萊恩?
這個總結就是我上面警告的那種混亂的一個例子。
如果您仔細考慮這些設備的實現細節(如果您還沒有,請閱讀並充分消化我在上面發布的
John Swenson 的鏈接,該鏈接解釋了一種此類產品並為進一步理解提供了一個良好的框
架),很明顯這些設備是在低級別代理 USB 數據包,而不是 USB 音頻協議本身。
這意味著無需考慮“授予訪問權限”或“干擾”。Roon 通過這些設備查看 DAC 的時鐘,
就像通過任何其他 USB 集線器一樣。
100% 明確:此類設備中完成的時鐘恢復與音頻時鐘無關。它們在不與音頻播放或音頻採樣
時鐘同步耦合的層中對 USB 數據傳輸位進行時鐘恢復。
Q:我想就是這樣@加斯曼的問題是:Roon 使用 DAC 時鐘信號將音頻流拉至網絡音頻適配器
時會忽略單獨的時鐘或其他 USB 增強功能嗎?既然答案似乎是“也許”,也許你們可以
指出一些這樣的“增強”產品,它們能夠為 Roon 提供增強的時鐘信號以用作參考時鐘?
也許在此類產品中尋找特定的功能/技術可以幫助我們確定它們是否被 Roon 忽略?
之所以@加斯曼的問題沒有得到明確的答案是因為它使用“時鐘”這個詞的方式比他引用
的我最初的陳述更不精確,這造成了歧義。我說的是採樣時鐘,它不屬於這些 USB 增強
器產品的範圍。
這就是為什麼我開始解釋系統中的一些不同時鐘,而不是直接回答一個令人困惑的問題。
“為 Roon 提供增強時鐘信號以用作參考時鐘”的想法完全沒有意義。這東西不是這樣工
作的。如果 USB/數據傳輸時鐘和音頻時鐘的概念混淆在一起,就不可能對此進行清晰的
討論。

Q:似乎即使在最簡單的 PC 音頻鏈中,在任何給定時刻都有許多“時鐘”在運行,而不僅僅
是 DAC 中的時鐘
這是事實,事實上,在許多 DAC 中,根據產品的設計及其功能集運行多個時鐘。例如,
具有集成流卡的 DAC 將具有管理 DAC 本身的時鐘(或多個時鐘)以及在流卡上運行處理
器的單獨時鐘(或多個時鐘)。
Q:人們可以合理地假設,從理論上和可測量上來說,其中任何一個“更好”(更準確,噪音
更少),數字音樂的解碼和播放就會“更好”,甚至可能是可聽的
然而,這並不完全正確。RAAT 的運行級別高於網絡硬件本身。為了大大簡化事情,它在
核心上分配一個緩衝區,在端點上分配另一個緩衝區。端點緩衝區可以位於連接的計算機
、流媒體卡等中。核心將數據放入其本地緩衝區,DAC 使用任何適當的接口從其本地緩衝
區中提取數據。核心僅看到其本地緩衝區,DAC 也僅看到其本地緩衝區。由 RAAT 協議來
管理兩個緩衝區之間的數據傳輸,並確保兩個緩衝區都不會太空或太滿。
為什麼這很重要?
嗯,DAC 只能從本地緩衝區提取數據,因此它不關心上游管道。核心只能將數據放入其本
地緩衝區,因為它不關心下游管道。
RAAT 管理兩者之間的數據傳輸,為了確保從核心到 DAC 的所有位完好無損,它使用網絡
本身提供的較低級別的設施來確保完整性。如果數據包丟失,則會發送新的數據包並按正
確的順序放入緩衝區。腐敗?一樣。在大多數情況下,緩衝區足夠大,以便在 DAC 不耗
盡數據或內核填滿其緩衝區的情況下進行糾錯過程。
請記住,我在這裡非常謹慎地使用“數據”一詞,因為這就是此時的音樂。它是一個位流
,是正在播放的文件的副本。這是一個異步過程,對 DAC 的模擬輸出沒有影響。RAAT(
和網絡堆棧)正在促進核心和端點之間的非常聊天的對話。他們確保文件(不超過緩衝區
的大小)從核心複製到端點。
傳輸介質上使用的時鐘對 DAC 發出的聲音的影響為零,因為 DAC 所做的所有操作都是從
本地內存緩衝區播放。它不知道,也不關心這些位在進入緩衝區之前發生了什麼。如果交
換機或網絡接口中的時鐘滿足傳輸機制的規範,則數據傳輸過程幾乎不會出現任何問題。
如果他們不這樣做,那麼就會出現更大的問題。
這是一個異步過程。根據定義,傳輸過程的計時(時鐘)與解碼過程完全分開。緩衝區將
以可變速率填充和清空,但只要 DAC 緩衝區中有足夠的空間,播放就會可靠地繼續。
這里區分的關鍵是數據和信號之間的區別。正在播放的文件不會變成信號,直到其位實時
通過 DAC 。在從 DAC(或端點)的本地緩衝區中提取這些位之前,這些位與用於文檔、
圖像甚至本文的位沒有什麼不同。
我理解發燒友不斷嘗試“改進”事物的願望,而這種行為確實是這種愛好的基礎。這在過
去更容易做到,因為大多數與物理和變化相關的概念不僅很容易被證明,而且可以用一些
邏輯解釋來支持。數字根本不是這樣,因為許多概念是反直覺的,而且解釋要復雜得多。
如果將流媒體混入其中,問題就會變得更糟。大多數音頻設備製造商對網絡如何運作以及
網絡可能或可能不會對實際播放產生影響幾乎不了解。可悲的是,這對那些花費辛苦賺來
的錢來解決實際上不存在的問題的消費者產生了負面影響。

Q:根據您的描述,通過將核心和播放器放在同一設備(NAS 上的文件)中從等式中刪除
RAAT 是否會對 SQ 產生任何影響?
理論上,只要 DAC 手頭上有足夠的數據來以適當的速率執行解碼,數據緩衝區的維護方
式就不會有什麼影響。問題是,當您不控制所有變量時,將緩衝區保持在適當的水平實際
上是非常困難的。

為了維護系統,您需要主動監控和調整龍頭上的閥門以維持填充率,以確保永遠不會讓水
位低於設定的最低水平。您還需要確保進行調整以確保不會超過安全最大值。您需要對高
水位線和低水位線進行預測,並對通過龍頭可用的水量變化和實際排水率的微小變化做出
反應。
這就是 RAAT 正在做的事情。它對 DAC(排水管)的時鐘速率進行建模,以了解浴缸是如
何被清空的。它還對網絡性能做出響應,以確保填充率不會允許緩衝區溢出或不足。
它甚至比這更複雜,因為核心側還有一個桶,通過網絡“排出”到 DAC 側的桶,並且桶
的大小根據所涉及的採樣率而不同。
現在想像一下對區域進行分組是多麼複雜(特別是如果每個區域有不同的採樣率要求)。
區域浴缸需要以絕對鎖定的步驟排水才能使其工作,但您無法控制連接浴缸的管道!
Q:或者在正常運行的網絡環境中,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 可以對遠處緩衝區的行為進行建模,那麼就可以確保它始終以不會允許其溢出
或耗盡的速率發送數據。
作者: elguapo (HPHT Synthesized)   2023-07-11 21:11:00
我不知道您能否接受我截圖給您的內容,那個是 Roon 創辦人寫的。Roon 會綜合 endpoint 回傳的時鐘資料,去比對 Roon 本身的系統時鐘的差別,然後建立一個預測模型,用這個模型去送信號。這時系統時鐘主宰信號發送,畢竟這時的控制權是 Roon,不是 DAC。
作者: qo3650 (江湖一把刀去一下 在看要)   2023-07-11 21:13:00
有人實測一下有沒有差ㄇ 個人看到chart回穩反射性就覺得聲音好聽了
作者: greg7575 (顧家)   2023-07-11 21:21:00
一整篇沒一段是看得懂的,該讓賢了
作者: elguapo (HPHT Synthesized)   2023-07-11 21:24:00
Endpoint 的接收 buffer 估計也是 software buffer(RoonBridge 是至少 layer 3 的軟體);software buffer 就會吃到 endpoint 的系統時鐘。
作者: greg7575 (顧家)   2023-07-11 21:25:00
緩衝區用完或爆滿是爆音和跳針嗎無論如何,跟中原標準時間都沒關係啊
作者: elguapo (HPHT Synthesized)   2023-07-11 21:36:00
我提議的對時對象是立即可用且免費的資源。如果@greg7575不想和NTP對時也無妨,只要在自己環境裡面選出一個參考時間就能達到一樣目的。兩個端點時間同步,對於緩衝的使用率就能更有效率的掌握,也算幫助 Roon 所說的不完美那一塊。
作者: greg7575 (顧家)   2023-07-11 21:39:00
好喔。我覺得這舉動沒意義啦,你覺得有意義很好啊意思是這個舉動也許限縮到對roon有效而已對吧對apple music的有效在哪?擴大解釋到"以電腦為播放"會不會太舒服了
作者: elguapo (HPHT Synthesized)   2023-07-11 21:49:00
我只是以白紙黑字的Roon拿來做example。另外我在我的原貼也提到macOS的Audio MIDI Setup也有對不同時鐘去re-sampling的機制,只要涉及到取樣率調整的運算,都和系統時間直接關係,希望您能理解。我的提議不用錢,只要作業系統對時部分調整一下設定就好,也不需要這麼排斥。
作者: m9172250 (bahpomet)   2023-07-11 21:51:00
Buffer:當我塑膠?
作者: greg7575 (顧家)   2023-07-11 22:02:00
我覺得不對的事我不做啊。我可以排斥吧。不能持反對意見要先說啊這篇發文貼了一大堆證明你錯了,還不能排斥喔
作者: elguapo (HPHT Synthesized)   2023-07-11 22:07:00
請問我那邊有錯?請指正。@oswyn 那個clock source selection只是為了系統時鐘resampling運算時的參考;發送的時候仍是軟體在發送。
作者: greg7575 (顧家)   2023-07-11 22:20:00
像EAC做offset的感覺,對同時播放錄音設備的檔案sync跟中原標準時間真的完全沒關係,講到我都覺得煩
作者: m9172250 (bahpomet)   2023-07-11 22:23:00
作者: elguapo (HPHT Synthesized)   2023-07-11 22:26:00
1. 建議看一下 AES67 規範(我是指 AES 文件商店購買的那份),針對介質使用 IEEE1588 作時鐘同步的規定。2. 不知您有否用過 Audio MIDI Setup 堆積三到四個多聲道DAC的經驗?我蠻建議您實作一次,去觀察 drift correction 的動作。我就次打住,直到您有答案為止。
作者: m9172250 (bahpomet)   2023-07-11 22:33:00
不要這麼壞好嗎
作者: chiyoda (博愛的千代田提督)   2023-07-11 23:10:00
問題其實很簡單,覺得有差的一方測量DAC出來的訊號就好有用對時工具出來的訊號和沒有用的訊號不一樣就能證明了如果有人認為這個量不到,那就請聽得出來的人蒙上眼,讓其他人隨機撥放,10次猜對9次也行,這樣做為的是排除"非聽覺性干擾
作者: tienam (已有太多鍵盤)   2023-07-11 23:21:00
我覺得讓電腦與NTP Server對時,是種樂趣,但音色沒有影響
作者: dancehotdog (長大就知道了)   2023-07-11 23:22:00
弱弱的問 那是不是usb hub 只是改善了雜訊或5v 訊號沒有影響到dac
作者: chiyoda (博愛的千代田提督)   2023-07-11 23:30:00
"有感"很有可能是"非聽覺性因素"影響阿
作者: djboy (雞尾酒)   2023-07-11 23:50:00
O大文必推!
作者: yys310 (有水當思無水之苦)   2023-07-11 23:56:00
事實 難看就先被噴爛了
作者: stupidHNG (stupid)   2023-07-12 00:21:00
原因是什麼怎麼不重要?不然搞科學是為了什麼?安慰劑吃了也有感,吃安慰劑可以治病嗎?
作者: icekiba (冷風寒)   2023-07-12 00:31:00
網內互打
作者: broskwlin (kkww)   2023-07-12 00:37:00
聽個音響是要治病嗎...最可能患得的大概是換換病吧
作者: yys310 (有水當思無水之苦)   2023-07-12 00:47:00
專治換換病
作者: icekiba (冷風寒)   2023-07-12 00:49:00
換音響不如換老婆我看是想咪兔
作者: comipa (綾崎若菜家御用)   2023-07-12 05:56:00
推 不過機翻還是比較難吃XD 還是原文舒服多了
作者: greg7575 (顧家)   2023-07-12 07:08:00
覺得很煩啊,任何設備計算時間都是用晶振發出的訊號算用48MHz的就是累滿48M個抖動定義為一秒晶振爛,對設備而言還是累滿48M個抖動為一秒這個狀況下,可能48M個抖動跟實際的一秒就有差異能顯示時間的程序會去抓48M個抖動來顯示時間的"一秒"無論怎麼軟體校正,爛晶振抖出來的一秒就不是一秒原原發文的一直覺得軟體校正就能讓爛晶振輸出準確一秒從他第一篇就講了,一直堅持他的"理論"。這有什麼辦法不過知識有盲區,我覺得很簡單的事不見得所有人能接受基本的觀念都錯了,身體本能的排斥很正常吧至於DAC的緩衝就是DAC會從資料暫存庫裡拉貨出來DAC看到音檔是44.1kHz的話就是拉這麼多出來播一秒apple music暫存直接機八大的給你好幾GB來存暫存裝的滿滿的就不用怕串流倉庫不夠播foobar也能設暫存的量,不過很精細的說那是另一件事反正原原po都說他就此打住了,我就這坨一次講完就算你去抓中原標準時間回來,爛晶振還是堅持他的一秒你的電腦顯示的時間是一回事,爛晶振的抖動方式不會變第一篇我就舉LP的例子,你不求轉速穩定而是覺得每15秒拉一下碟盤"校時"就好殊不知這"校時"一點意義都沒有,轉速一樣不穩音樂照播如果你的"校時"有意義,那你的音樂要每15秒跳針一次沒聽到跳針的話,表示校時跟dac的clock完全沒關係在座各位有誰家的電腦按下校時,音樂會跳針的嗎?戰過很多次了,數位出錯就會爆音。沒爆表示沒差啊至於DPC Latency的問題不在這談,更煩
作者: elguapo (HPHT Synthesized)   2023-07-12 09:45:00
@greg7575 關於改系統時鐘會造成破音這件事,歡迎來我家坐坐,我demo給您看/聽。
作者: bt092001 (一條魚)   2023-07-12 10:18:00
事情很單純,就是serdes 原理而已,決定品質的就是DAC跟RX 本地clock性能,其他都只是暫存跟latency
作者: icekiba (冷風寒)   2023-07-12 10:43:00
要確定是改進捏你進來了嗎? 我是說訊號
作者: greg7575 (顧家)   2023-07-12 11:22:00
做任何事都會改變,而這個改變的原因不能亂講。撐傘能遮陽,而不是撐傘把太陽變弱
作者: elguapo (HPHT Synthesized)   2023-07-12 11:33:00
@greg7575 來我家 我 demo 眼見耳聽為憑
作者: m9172250 (bahpomet)   2023-07-12 11:38:00
直接人工耳啊
作者: elguapo (HPHT Synthesized)   2023-07-12 11:43:00
對了 也歡迎 @Oswyn 來我家 我可以demo一些CLOCK_REALTIME 對音質的影響。邊操作邊解釋應該更容易溝通。
作者: m9172250 (bahpomet)   2023-07-12 11:43:00
大家都能聽到
作者: greg7575 (顧家)   2023-07-12 11:44:00
錄一段校時會爆音的上來瞧瞧,長知識
作者: jakkx (風藍)   2023-07-12 11:49:00
這種不影響就是進步的原動力啊。即使原因可能不是當初認為的那一個
作者: m9172250 (bahpomet)   2023-07-12 11:51:00
那可以去拜讀一下量子力學
作者: elguapo (HPHT Synthesized)   2023-07-12 12:03:00
一邊講解一邊示範效果最大 我是真的希望G大和O大來我家家訪 無意引戰 而是把事實呈現給兩位會比在這裡文字描述有用的多
作者: greg7575 (顧家)   2023-07-12 12:15:00
你高興就好
作者: lacer (期末啦)   2023-07-12 12:25:00
是否可以把引用跟自己意見區別明顯一點 不然一下翻譯一下自己論述 也可以用gpt把來源文章摘要 這樣會更棒
作者: elguapo (HPHT Synthesized)   2023-07-12 12:30:00
G大不是積極的證明在下是錯的嗎?我同意您來家訪後,您來公布家訪細節,包含截圖、照片和對話(要錄音也行)。
作者: icekiba (冷風寒)   2023-07-12 12:35:00
那…我去印紅布條 第一屆音響版版聚
作者: greg7575 (顧家)   2023-07-12 12:38:00
所以我不去就是我講的都錯的意思嗎?好喔那我不去,我俗辣,你對。請繼續開發用軟體改變晶振的能力:)我覺得我很友善了。嘻嘻
作者: lacer (期末啦)   2023-07-12 12:44:00
喔 明白了 看來ptt的格式 比較適合引用摘要 一大段真的不簡單 如果有QA以外的資料歡迎分享喔 不大想只看Roon的說法
作者: greg7575 (顧家)   2023-07-12 12:47:00
晶振運作原理都講了,只想要輸贏。那你贏
作者: jwchen119 (jwchen119)   2023-07-12 12:51:00
支持家訪,最好可以作雙盲測試
作者: elguapo (HPHT Synthesized)   2023-07-12 12:52:00
說到對時後會不會跳針… 依據AES67 的文件,以 48KHz 來說,每 24.86 小時會 overflow,若把信號和時間在那時候對齊,是會跳針的。 https://i.imgur.com/MZcINCN.jpg我一直以來都在講系統時間,晶振只是系統時間的參考信號,我不知道那邊溝通出問題?O大,您前個回覆,更讓我想把您奉為貴賓來接待,讓我仔細的和您解釋並示範吧。
作者: greg7575 (顧家)   2023-07-12 13:04:00
多開幾個程式讓dpc latency牙起來。改變音質很簡單不用牙到爆音的程度,負載重就很有感了。尤其是nv的驅動,沒事做還可以牙起來叫它做點事反而觸發降低latency。魔法驅動值五千大師可以略過我,我在跟其它看戲的解釋可能的狀況
作者: comipa (綾崎若菜家御用)   2023-07-12 13:09:00
也許只是因為一直對時 cpu進不去c-state
作者: greg7575 (顧家)   2023-07-12 13:10:00
cpu運作的鬆緊對音質影響也很大,樓上突破盲點win11顯示秒數就不能休眠。cpu會一直牙
作者: m9172250 (bahpomet)   2023-07-12 13:39:00
我覺得眾多燒友已經很極力 用人可以聽懂的語言去解釋了,還有談論的意義嗎roon那篇原文 連機翻都講到可以如此白話
作者: greg7575 (顧家)   2023-07-12 13:46:00
無法證明是校時改變音質還是校時軟體改變音質任何程式要顯示秒都要叫cpu call晶振惡靈古堡移植版的fps越高小刀傷害越高程式喊了什麼要拆開來看才知道
作者: Zyar (Zyar)   2023-07-12 14:38:00
支持樓主去家訪 都吵這麼兇了 不如家訪吧 親眼論證一下孰對孰錯再分享給大家確切結論
作者: m9172250 (bahpomet)   2023-07-12 14:48:00
人工耳不是快速便捷 順便大家都能聽
作者: chibob (lead)   2023-07-12 14:48:00
家訪可以啊 先講好有甚麼儀器可以驗 不然也只是一起舒服
作者: icekiba (冷風寒)   2023-07-12 14:49:00
要看怎麼舒服法幾個SSiltech
作者: m9172250 (bahpomet)   2023-07-12 14:51:00
幾個hHarbeth
作者: icekiba (冷風寒)   2023-07-12 14:53:00
0.3 0.5 還是 1 我說線徑
作者: yys310 (有水當思無水之苦)   2023-07-12 14:54:00
錄音錄起來每次都不同 人工耳是想要用啥指標來看?
作者: m9172250 (bahpomet)   2023-07-12 14:56:00
沒關係 因為差異性一致至少要聽出有無變化即可 不求還原
作者: chibob (lead)   2023-07-12 15:13:00
發散也是差異 收斂也是差異 大膽假設 小心求證
作者: icekiba (冷風寒)   2023-07-12 15:15:00
我有個大膽的想法
作者: chibob (lead)   2023-07-12 15:19:00
快收起你大膽的想法
作者: m9172250 (bahpomet)   2023-07-12 15:29:00
我有個大
作者: icekiba (冷風寒)   2023-07-12 15:36:00
大什麼大
作者: sunyanwen   2023-07-12 16:08:00
AES67是fully-synchronized system,沒有drift的問題,VAD只能做PTP Slave,VAD的音頻時鐘只能鎖定在PTP GM上,因為是burst形式的data,所以只要鎖定還在,音頻就沒問題,NTP不能加入鎖定,自然是沒有用的
作者: lacer (期末啦)   2023-07-12 16:13:00
我看過原文才問的 因為這只是Roon的說法 問題是原本的發文不是只適用RAAT 你們講的不完全一樣也 雞同鴨講了
作者: max0427 (真心為你)   2023-07-12 16:14:00
原原po的討論口氣很客氣,我也相信他付出努力並無償分享完全出自好意,值得我這樣的路過鄉民給予感謝。但是即便認錯很困難,這還是值得追求的美德,因為您真的無法證明您做的改變對數位音樂播放有益,[email protected].
作者: tienam (已有太多鍵盤)   2023-07-12 16:25:00
對時就是種樂趣啦,無法改變音色的,但會增加server負擔(X)
作者: elguapo (HPHT Synthesized)   2023-07-12 16:35:00
@sunyanwen VAD 是 PTP software slave,輸出的封包 timestamp 是來自系統時鐘。
作者: sunyanwen   2023-07-12 16:51:00
不需要考慮timestamp的問題,所有設備都頻率鎖定在PTPGM上,playback的buffer+來自PTP GM的locked audio clock就可以保證絕對穩定的播放
作者: bt092001 (一條魚)   2023-07-12 16:53:00
EPHY LPHY不是完整封包根本認不得,DAC 本體吃的都是re-sample PLL。當然noise injection 是另一回事要分開看
作者: elguapo (HPHT Synthesized)   2023-07-12 17:06:00
https://i.imgur.com/5FzRNAS.jpg @sunyanwen 謝謝您的意見。或許是我看著 VAD audio clock 上上下下的不太舒服吧。其他器材只有 +-1ns 的變化。截圖是經過local NTP 對時後穩定的結果。若純以系統自動對時並處於 free clock 狀態的話,瞬時變化會 >100ns。AES67 標準 frame buffer 是 1ms。這樣的不穩定我個人認為有必要進一步管理。補充:VAD 顯示的 audio clock 狀態即是 system clock的狀態
作者: tienam (已有太多鍵盤)   2023-07-13 00:44:00
win11 KB5028185更新,啟用moment 3,工作列讀秒功能回歸.可以設定工作列讀秒功能,讓CPU不要沉睡.
作者: Myt33   2023-07-13 00:52:00
macOS裝caffeine會不會也有類似的效果?
作者: elguapo (HPHT Synthesized)   2023-07-13 08:34:00
1. AES67 精度規範沿用 AES112. DXD 352800 samples per second,sample 與 sample間隔約 2.83us,用這個間隔看 100ns 的 jitter 又會是多大的影響?這只是單一聲道,若為12聲道DXD?
作者: greg7575 (顧家)   2023-07-13 09:07:00
sample跟sample之間沒有間隔。是晶振幫忙決定晶振誤差的時基抖動有空我會來留幾個字晶振的精度決定一切,不是你一直講的中原標準時間。心跳決定你是人以及行為,而不是西元民國
作者: elguapo (HPHT Synthesized)   2023-07-13 11:04:00
A 電腦用 AES67 傳音訊給 B 電腦,請問晶振在哪裡?A電腦用Dante傳音訊給B電腦,B電腦再用Ravenna傳給C電腦,請問晶振又在哪裡?時鐘要依據誰?
作者: greg7575 (顧家)   2023-07-13 11:59:00
經過這幾天的討論,是依據你的感覺。
作者: elguapo (HPHT Synthesized)   2023-07-13 12:00:00
A 電腦 macOS 跑 NAA 守護程式當作 B 電腦的 HQPlayer input,請問晶振在哪裡?時鐘又是誰為主?
作者: greg7575 (顧家)   2023-07-13 12:00:00
晶振造時間的本質我講再多次也無法改變你的感覺發給外國人教育他們,我是不受教啦。晶振在主機板上面,你把它拔了試試能不能開機反正你說會依靠源頭時鐘嘛留下你覺得有用的那個晶振,其它全拔了齁
作者: elguapo (HPHT Synthesized)   2023-07-13 12:04:00
以上三種狀況開大buffer確實就能解決問題,但若環境要求要越即時越好,那麼你會怎麼做?電腦主機板的晶振管音訊samples的發送?
作者: greg7575 (顧家)   2023-07-13 12:06:00
拔掉啊,你都說晶振沒用。
作者: m9172250 (bahpomet)   2023-07-13 12:07:00
buffer:很趕嗎
作者: elguapo (HPHT Synthesized)   2023-07-13 12:09:00
我只問那三個場景你所謂的晶振在哪裡。你一直說這音訊資料是晶振處理就好?
作者: greg7575 (顧家)   2023-07-13 12:14:00
那剪掉嘛。尖嘴鉗能搞定的事,找我輸贏幹嘛
作者: elguapo (HPHT Synthesized)   2023-07-13 12:20:00
因為我認為您應該是學有專精,有我不足的知識,來求教的,謝謝。
作者: greg7575 (顧家)   2023-07-13 12:20:00
文字稿本身沒有時間,內容傳輸只要保證正確就好你看我沒有很正常啊,我都舉凡人的例子不用太抬舉我。嘻嘻
作者: elguapo (HPHT Synthesized)   2023-07-13 12:21:00
O 大您的回文不就寫了「時間」?
作者: greg7575 (顧家)   2023-07-13 12:24:00
人家的時間不是你的中原標準時間我會保持隨時出來廢話,你要忍耐
作者: m9172250 (bahpomet)   2023-07-13 12:27:00
http://i.imgur.com/3tUQk1P.jpg這是守序中立的晶振
作者: greg7575 (顧家)   2023-07-13 12:30:00
是不是有人以為晶振裡有小精靈,可以用軟體調整啊
作者: elguapo (HPHT Synthesized)   2023-07-13 12:33:00
VCXO:當我塑膠
作者: greg7575 (顧家)   2023-07-13 12:36:00
你已經調出ns級的正確,去笑那些晶振廠啊自信這種東西用循環論證可以膨脹很快你的校時軟體可以修正晶振的誤差,泰褲啦
作者: elguapo (HPHT Synthesized)   2023-07-13 12:50:00
留言怎麼會有情緒性反應?是因為我的問題太簡單而損人尊嚴嗎?
作者: greg7575 (顧家)   2023-07-13 12:55:00
你是不是查了晶振原理之後大徹大悟了我句句都在引導你考查真相啊你的校時軟體能改變晶振嗎?快回答我有問題就問,大家回答。耳機板那邊你也去看看
作者: elguapo (HPHT Synthesized)   2023-07-13 13:08:00
我從頭是一直在講「系統時鐘」,是閣下一直在扯晶振,請勿不當連結。
作者: greg7575 (顧家)   2023-07-13 13:26:00
可惜我以為你大徹大悟了無法用任何校時去改晶振。改顯示時間只是改爽的而已偏偏我見識少只能舉通俗的例子。讀稿機不會因為晚一兩秒開始唸而改變內容語速也不會改變內容,只會改變聽感。
作者: elguapo (HPHT Synthesized)   2023-07-13 14:00:00
我誠心邀請O大來我家坐坐,我必奉為上賓,分享同步乙太網路和AoIP的一些實作以及performance optimization方法,並實作可重複呈現的收系統時鐘影響的音質變化(這真的不用AB test,幾個簡單指令現象就會發生);也或許我的methodology有問題,也歡迎指正我的問題盲點。我也同意由您來貼家訪後的文章,把您所見所聞都寫出來(包含照片、錄音等)。
作者: greg7575 (顧家)   2023-07-13 14:00:00
追求聽感是計較語速還是計較幾點幾分開始唸呢?他前面就說過了,有改變也不能證明你的理論是對的。你的盲點這幾天大家講很清楚而你堅持只要見面輸贏。至於你認為我沒學識只會搗亂,我欣然接受。
作者: elguapo (HPHT Synthesized)   2023-07-13 14:15:00
因為我講的這些現象要一邊講一邊做才好溝通,為什麼會有見面輸贏的錯覺?
作者: m9172250 (bahpomet)   2023-07-13 14:30:00
cpu:好啦 我有在做事 不要再敲我了
作者: greg7575 (顧家)   2023-07-13 14:45:00
原理以及思辯方式都講這麼清楚,還能有什麼嗎?從一開始就沒否定你的行為會影響音質我否定的是你對於你的行為的解釋有認同你的解釋的人麻煩也出個聲
作者: m9172250 (bahpomet)   2023-07-13 14:46:00
既然有差 要表現出來 不能人工耳錄一綠直接丟出來嗎
作者: greg7575 (顧家)   2023-07-13 14:46:00
不要以為是引戰還是霸凌,我一直想幫你。裝忙的cpu程式在耳機板也有人貼你的第一篇的立論建立在校時軟體能改變晶振這個立論錯誤,後面都不用提。找誰家訪都不能改變這個錯誤立論
作者: elguapo (HPHT Synthesized)   2023-07-13 15:09:00
請問我文章哪一段敘述是要改變晶振?
作者: greg7575 (顧家)   2023-07-13 15:10:00
依有學過計算機原理的人都知道,時基由晶振決定你能用校時軟體改變時基,這就是你的超能力也許因為你沒有這個觀念才會有這麼多事。沒有觀念學就有了,不是什麼人格品德的批評https://i.imgur.com/LlT6dRK.jpg
作者: kshieh   2023-07-13 15:17:00
校時對AoIP timestamp sync來說是極為重要的「必要之惡」。而這裡99%的版友都是用實體訊號線(同軸/光纖/HDMI)直連,完全不需要擔心這個因素,也難怪原原po會找不到知音
作者: greg7575 (顧家)   2023-07-13 15:17:00
https://i.imgur.com/eBUXCAj.jpg找chatgpt家訪,告訴他你的重大發現
作者: elguapo (HPHT Synthesized)   2023-07-13 15:21:00
我只問我的原貼哪一句話在說對時是改變晶振,結果你拿chatGPT?
作者: greg7575 (顧家)   2023-07-13 15:25:00
不然你說說你對於電腦的時間定義好嗎?如何在電腦上產生一秒。什麼是時間什麼是時鐘請你大方的分享你的定義。謝謝你。越詳細越好你的校時軟體能均勻時間就表示你能改變晶振呀
作者: elguapo (HPHT Synthesized)   2023-07-13 15:43:00
請摘出我原貼裡面,閣下認為我有表示是用對時工具改變晶振的任何文字。有就截圖貼出來,沒有就說沒有。
作者: icekiba (冷風寒)   2023-07-13 15:45:00
Steins;Gate 先從香蕉開始吧
作者: elguapo (HPHT Synthesized)   2023-07-13 15:48:00
對時是對 CLOCK_REALTIME 校正,您該不會不知道什麼是 CLOCK_REALTIME 吧?
作者: greg7575 (顧家)   2023-07-13 16:45:00
好啦你對。我人生不會再跟你起爭議。我保證
作者: shaylin3 (sevende)   2023-07-13 16:48:00
現在聽個音樂,知識量要這麼豐富了嗎
作者: icekiba (冷風寒)   2023-07-13 16:52:00
一直都是
作者: downlevel99 (幫西好嗎)   2023-07-13 18:59:00
沒有一個字看得懂的 我覺得可以退坑了
作者: lee28119 (德莫尼克)   2023-07-14 09:46:00
整串看完的結論是沒有同步需求就不用掛主時鐘 靠AD/DA的時鐘就夠了這樣嗎?

Links booklink

Contact Us: admin [ a t ] ucptt.com