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

原文恕刪 以下簡易解釋優化front end， 的DATA或是CLK是相對比較無效益的， 如有錯誤再請高人補充或改正， 另外關於介面傳輸干擾，包含PG noise，crossing talk ，ISI，SSO，GND bounce ，PSR R問題先不在此列。 如下圖截至ESS提出的原理 左邊紅圈為CDR/DPLL 因介面傳輸有非理想效應， 這些傳輸不佳訊號不能被直接數位電路使用， 所以需要重整DATA， 右邊為OSC 或是本地CLK 專門給DAC cell使用， 當CLK正或負源觸發後將DATA送給DAC， *OSC物理電器特性是一個固定低頻高性能的CLK 故我們知道最終決定抖動性能就是這個本地CLK，前端很差或是被DIGITAL PHY暫存都只是 被看作latency 的表現不影響最終性能，其他類比干擾暫不在此討論。 https://i.imgur.com/JgIngMU.jpg 這時有人會說DATA錯了怎辦？ 通常晶片內有digital PHY或是controller 如果DATA效能差到規格外，搞得PHY神經了，是會解不出來或是time out，聲音是打不出 來的。 內部數位的過程因為設計時晶片EDA tool都會評估DATA 跟CLK的skew故可以放心，如果真 有問題量產晶片測試時會被刷掉不會流到消費者端。 以下兩圖是市面上販賣的主機板內建以及外接USB DAC 晶片的data sheet ，紅圈所示為 這個原理的實踐 https://i.imgur.com/7XIGNUe.jpg https://i.imgur.com/IW2N5Bg.jpg 感謝板上先進，如有錯誤再請板上先進修正 -- 感謝補充，的確是這樣理解，如果狀況大到PHY看不懂，資料是送不出來的 07/13 17:18 這樣意義不大，因為聽到的聲音的CLK是DAC 本地CLK在送，電腦端的東西也只是被DIgita lPHY存起來視為系統latency 而已 坦白說只要合規前端並不重要， 因為到DAC前可能過了無數個PHY，他們之間只要DATA對， 其他firmware,software,hardware 之間 如何handshake 轉了什麼格式的資料或是時鐘，只要合規走最高規互相能看懂就好， 但詳細還要去看各個介面的spec 。 最終性能決定還是在最終段 內文有說排除，類比串擾，這邊講的是系統理論，CLK一樣DATA一樣就是一樣，但這裡沒 講類比串擾哦，系統隔絕能力，noise 樣態大小這些都是可能不一樣的點 而且chip 都還有PVT的偏移，要計較的話多的是可以計較的 → dancehotdog: 後就不見得是特定族群喜歡的 07/13 22:03 拉很高那有沒有代價，這個代價也可能影響其他電器特性 並沒有很簡單，這些相容性情況組合變因有無數種，不能感覺， 如果要這樣算今天85度跟30度電器特性改變10%人耳是否能聽出來？ 或是人耳是否能人耳分辨FF SS chip? 而且不是是假設啊，系統理論事實上會發生啊， 今天假設高溫你今天GPIO device剛好在FF， DAC core剛好在SS如果SSO發生， gnd bounce墊個10-50mv你DAC INL DNL早就掉了， 而且這個刷量產因為在規格內還刷不到， 還有dac chip廠不是系統廠前端或是系統端沒做好是管不了的， 然後你今天VBUS是吃線電或是DCDC，chip看到noise長相也不同， 而且chip當下的PVT的PSRR長相也有無數組合 相容性的東西不可能做到這種程度，只能定義一個可接受誤差範圍作為規格讓系統go起來 電器特性的改變就是系統規格可以接受的誤差 推 icekiba: 高價的隔離能力搞不好還很差XD 07/13 23:15 隔離能力是chip隔離還是PCB技巧？還是chip間相容性？ 切的很乾淨是多乾淨？有沒有代價或副作用？ 或是加強LDO?今天拉高PSRR，瞬間抽電的恢復能力變差就是代價， 電路的東西要取捨的東西太多不是非黑即白沒有無敵的那種事 您誤會這邊講的合規跟走最高規的意思， 隨便指一個案例，能走U2傳就不會走1.1， 原資料能傳32bit 192k就不會下降到16bit 48k 硬體支援的話都是用最齊全的資料流在傳 根本不用管他Master clk用多少去敲，每家chip 還不一樣咧。 去調front end clk精度無意義， interface ISI jitter 超大，你前面多準，也都被介面傳輸jitter 搞超大這樣有用嗎？ 如果用對時角度去看你只是讓delay往前或往後而已，但重點不是延遲時間而是jitter 你前端jitter 是1ps或100ps都一樣，DAC如果5ps jitter 過了DAC 就是看DAC 5ps的jitt er 不知道這樣是否理解 不知道為何原po一直很在意延遲時間，早或晚打出data不影響聲音品質阿 應用不同啊，這裡是音響hiend 相關應用， 你今天聽音響會在乎聲音早1ms或晚1ms發出？還是比較在乎聲音品質？ 而且serdes 的原理使用本來就是會切斷前面的clk用自己的clk 對於DAC的系統的角度，前面不論花多少功夫再準再校正，DAC只會認為他是一個延遲時間 。 假如你是平行三部一樣的DAC，三部的jitter 量是一樣的，如果前端過的PHY或是cable 不同，這三部的延遲會不同，所以你要的應用是多部平行的DAC，同時發訊號？ 這樣理解你要的應用對嗎？ 如果是這樣的應用就是讓DAC吃同一個外接或是本地CLK且skew一致並且這幾部的DATA sk ew要在一個UI內，這樣就隔絕前端CLK並且DAC同時輸出 ASE67只能同步DATA skew到DA家門口 不確定原原po要的應用是不是多部DAC同時播放，感覺上是那個意思，但是其實那樣也 跟AES67無關，因為串列傳輸會隔掉上一級clk 我大致理解e大的想法但跨越PHY不是所謂的主時鐘概念，都是使用本地CLK，其他都是成 串封包內含DATA以及CLK的資料編碼，但不是用這個CLK在傳，走乙台網路就是用乙台網路 發射速度，封包內涵音訊的資料跟clk rate資料這些都被視為DATA，你所謂的主時鐘同步 對於系統只是同步DATA skew，而不是同步DAC CLK，這些DATA skew只要在一個UI內，兩 部DAC就不會看錯資料 這時文件定義的問題對於你只看dante 來說是，但是對於以最後一級為DA全系統來說的物 理意義不是
※ 批踢踢實業坊(ptt.cc), 來自: 223.137.239.156 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689237197.A.AFE.html

推 icekiba: 大腸麵07/13 16:38

→ evadodoya: 多加香菜07/13 16:40

推 djboy: 可能要在結論區加一句：「系統的GLOBAL CLOCK沒有對準， 07/13 17:03

→ djboy: 可視為前端有狀況，但是均己被DAC後端解決掉」07/13 17:04

→ djboy: 這樣子，原原PO才看的懂07/13 17:05

推 kshieh: 原原po有說到在USB DAC做resampling時需要準確的時間，才07/13 17:16

→ kshieh: 會算(interpolate)出正確的結果？ 07/13 17:16

→ kshieh: 更正：是電腦做resampling

推 Oswyn: 目前主流就是傳輸為異步，明示兩端被不同步的 buffer 分隔07/13 17:19

→ Oswyn: 而 DAC 還是工在同步模式，所以 DAC 依賴的時鐘源很重要07/13 17:19

推 greg7575: dpc latency 大到讓音樂起肖的狀況也蠻常發生(07/13 17:27

推 greg7575: 封包，你退下。07/13 17:28

推 comipa: 所以為什麼之前很多人玩PC訊源都是先幹了p/c state這類07/13 17:37

→ comipa: 另外電腦算什麼都不用準確的時間 是要準確的clk,連時間都 07/13 17:37

→ comipa: 是以clk為基礎算出來的. 電腦內有時間觀念的硬體大概RTC吧07/13 17:37

→ ganei: 玩過走USB 1.x的 DAC就知道DAC起乩其實也還好，重插RESET一07/13 18:08

→ ganei: 下而已(重新同步)，頂多一直斷電重開有點煩，等哪天受不了 07/13 18:08

→ ganei: 自然會換走2.0非同步的新機... (不便引發的購物衝動 07/13 18:08

推 icekiba: 1.1沒幾年就2.0化了 07/13 18:10

推 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: DAC ，這時的時鐘如何轉換？ 07/13 18:51

→ ganei: 記得2003年左右就有pcm2702的pcb可以玩，2.0 非同步的07/13 18:52

→ ganei: audio 介面出來要到2010去了(XMOS方案)，有本事拿Cypress07/13 18:52

→ ganei: 晶片或FPGA自幹的論外，這大概比日本製壓縮機還稀少07/13 18:52

→ elguapo: 更正: Mac A07/13 18:53

→ greg7575: 古早拿270x 蝦機八搭棚的一堆啊，好玩 07/13 19:40

→ greg7575: xmos 粗乃還是有一大堆receiver活得好好的( 07/13 19:41

→ greg7575: usb剛粗乃的時候cs8xxx這些轉IIS的很熱門 07/13 19:42

→ yamatai: 這種說法已經十幾年 還是沒解釋為什麼電腦不同聲音不同 07/13 19:50

推 djboy: 其實，現在都2023年了，AKM/ESS的高薪RD也不是吃素，能做 07/13 21:49

→ djboy: 能改的應該都全下了(除了COST DOWN版本，這也是盡力COST07/13 21:50

→ djboy: DOWN)。DAC IC 大概也就如此，除非有天才或是架構性的突破07/13 21:50

推 dancehotdog: 產品會往cp值發展 不太會只考慮音質 就像3C一樣 到最07/13 22:03

→ yamatai: 類比串擾 noise 樣態 也只是你的假設阿07/13 23:03

→ yamatai: 如果這麼簡單那 DAC 把隔絕能力拉高不就無敵了07/13 23:04

→ yamatai: 問題就是現在沒有任何 DAC 可以改變電腦不同聲音不同現象 07/13 23:05

→ yys310: 有哪台DAC隔離能力高到無敵了嗎？ 07/13 23:09

→ yamatai: 沒有吧 很強調技術的廠牌隔離能力都很高了吧 07/13 23:22

推 louis0407: 覺得這篇原Po講得很好xddd07/14 00:52

→ elguapo: 音頻資料在使用/傳遞過程若有吃到系統時鐘的部分，將系07/14 02:36

→ elguapo: 統時鐘校正，不正是呼應您說的「要合規走最高規」？07/14 02:36

推 greg7575: 電源線沒差的話，設備就不用買雙屏蔽超級小黑線了07/14 07:20

→ greg7575: 整台電腦都換掉，產生的改變也當然會存在07/14 07:21

→ greg7575: 即便是流水生產的，以高頻探頭為例。還是要各別校對07/14 07:22

→ greg7575: 只是現在沒生產出拉普拉斯的妖怪，沒辦法確定一切07/14 07:23

→ greg7575: 無論再怎麼電路隔離，元件以及機箱內的環境都會有噪07/14 07:24

→ greg7575: 噪除了電路，還有元件工作電磁波反射、外在電磁波引入07/14 07:25

→ greg7575: 跟夸父追日一樣，追不到。追的過程又產生新的問題07/14 07:25

推 greg7575: 版子上面元件間距，會不會產生渦流，一堆鬼故事07/14 07:29

→ elguapo: 行動無線通信，手機基本上也是一個DAC（最後要變成聲音）07/14 09:10

→ elguapo: ，按照您的意思，ITU-T對5G通信網路要求同步是沒有意義07/14 09:10

→ elguapo: 的事，對吧？07/14 09:10

推 kshieh: 我想e大應該是陷在AoIP的坑了，時間同步是為了接收端正確 07/14 09:36

→ kshieh: 的重組packetized pcm data，接收端de-packetized後，就無 07/14 09:36

→ kshieh: 需那個時間資訊，直接把pcm stream丟進去i2s audio i/f輸 07/14 09:36

→ kshieh: 出就可以了 07/14 09:36

→ elguapo: 應用沒有不同。AoIP 本質就是同步網路（用的是IEEE1588 07/14 10:07

→ elguapo: 的media profile），而AoIP也有 Hi-end 產品（Merging NA07/14 10:07

→ elguapo: DAC）。若照您的意思AES67的同步也是沒意義的，反正DAC07/14 10:07

→ elguapo: 都會修正一切。請問DAC會處理兩三個DAC之間的時間差異嗎07/14 10:07

→ elguapo: ？07/14 10:07

推 kshieh: 傳遞延遲就是在網路容量規畫時要考慮的，再來就是把QoS設07/14 10:43

→ kshieh: 好。pcm資料離開AES67網路後，DAC就是單純撥放而已07/14 10:43

→ kshieh: AES67的時間同步是重中之重。只是你可能吧AES67的工作範圍07/14 10:46

→ kshieh: 想得太廣了些07/14 10:46

推 kshieh: 看了一下Merging+NADAC的產品說明，他們有提到一句"it use 07/14 11:06

→ kshieh: s a professional protocol called RAVENNA to manage the 07/14 11:06

→ kshieh: data transfer and ensures a very high level of data i07/14 11:06

→ kshieh: ntegrity and a timing accuracy of 1 nanosecond"看起來07/14 11:07

→ kshieh: 是很優是吧？可是假如不走網路用同軸線直連(這台DAC也能直 07/14 11:07

→ kshieh: 連)的話，根本就沒有這個timing問題 哈07/14 11:07

→ elguapo: 有個軟體叫做「Dante Via」，可以把另一台電腦的 USB DAC07/14 11:11

→ elguapo: 變為 Dante network 的一部分。您可以拿這個東西實作：A07/14 11:11

→ elguapo: 電腦Dante，B 和 C 電腦Dante Via，B 和 C 電腦各掛一個07/14 11:11

→ elguapo: 不同品牌的 USB DAC，然後 A 電腦將 B 和 C 的 USB DAC07/14 11:11

→ elguapo: 作為 4ch 輸出（就當作做 2.2 分頻），請問主時鐘會是 07/14 11:11

→ elguapo: 哪一台電腦？那台電腦的時鐘來源又是什麼？ 07/14 11:11

→ elguapo: @kshieh Ravenna是AoIP的一種，符合AES67規範。 07/14 11:13

推 djboy: BT大辛苦了07/14 11:58

→ elguapo: https://i.imgur.com/FjcZmIN.jpg 07/14 11:59

→ elguapo: webinar 資料，描述是 local clock 被主鐘同步 07/14 12:00

→ elguapo: Fully 這個辭意應該不是只有 skew 07/14 12:01

→ elguapo: 對不起更正，”precisely” 07/14 12:02

→ elguapo: slide 是指出 local clock 是 GMC 的 copy* 07/14 12:08

推 kshieh: 我再讀了一遍e大提供的webinar投影片，的確是有提到若是fr 07/14 15:17

→ kshieh: ee run，alignment of streams是1/2 sample time 。以48kH 07/14 15:17

→ kshieh: z來算，約是10us。若pcm下i2s時能控制BCLK的起始時間，的 07/14 15:17

→ kshieh: 確能做到更精準的multi stream alignment… 只是一般家用 07/14 15:17

→ kshieh: 系統都是在傳mux好的雙/多聲道訊號，自然沒有alignment問 07/14 15:17

→ kshieh: 題。 07/14 15:17

推 kshieh: 我是覺得 不是大型場館的應用 明明可以有更可靠的方法 卻 07/14 15:39

→ kshieh: 硬要跑進水(ip network)裡，用來奧林匹克等級的泳技，結果 07/14 15:39

→ kshieh: 速度還是輸給陸地慢跑的阿伯… 07/14 15:39