PTT評價

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

看板Audiophile標題Re: [心得] 運用 Chrony 對時工具提升音訊品質作者
bt092001
(一條魚)
時間推噓20 推:20 噓:0 →:77

原文恕刪

以下簡易解釋優化front end,
的DATA或是CLK是相對比較無效益的,
如有錯誤再請高人補充或改正,


另外關於介面傳輸干擾,包含PG noise,crossing talk ,ISI,SSO,GND bounce ,PSRR問題先不在此列。

如下圖截至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


感謝板上先進,如有錯誤再請板上先進修正

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.239.156 (臺灣)
PTT 網址
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:37 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:52

icekiba07/13 16:38大腸麵

evadodoya07/13 16:40多加香菜

djboy07/13 17:03可能要在結論區加一句:「系統的GLOBAL CLOCK沒有對準,

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

djboy07/13 17:05這樣子,原原PO才看的懂

感謝補充,的確是這樣理解,如果狀況大到PHY看不懂,資料是送不出來的

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:12:19

kshieh07/13 17:16原原po有說到在USB DAC做resampling時需要準確的時間,才

kshieh07/13 17:16會算(interpolate)出正確的結果?

kshieh更正:是電腦做resampling

07/13 17:18

這樣意義不大,因為聽到的聲音的CLK是DAC 本地CLK在送,電腦端的東西也只是被DIgita

lPHY存起來視為系統latency 而已

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

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

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

greg757507/13 17:28封包,你退下。

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:36:25

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

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

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

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

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

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

icekiba07/13 18:101.1沒幾年就2.0化了

elguapo07/13 18:51感謝解說。但我的point真的不是DAC的design問題。場景:M

elguapo07/13 18:51ac A 用 Dante 連 Mac B,Mac B 用 internal looping 將

elguapo07/13 18:51音訊轉給 USB DAC。Dante 和 internal looping 是虛擬介

elguapo07/13 18:51面。請問音訊資料傳遞時,max A -> Mac B 傳 Dante 時誰

elguapo07/13 18:51是主鐘?到了 Mac B,Dante 借 internal looping 到 USB

elguapo07/13 18:51 DAC ,這時的時鐘如何轉換?

坦白說只要合規前端並不重要, 因為到DAC前可能過了無數個PHY,他們之間只要DATA對, 其他firmware,software,hardware 之間 如何handshake 轉了什麼格式的資料或是時鐘,只要合規走最高規互相能看懂就好, 但詳細還要去看各個介面的spec 。 最終性能決定還是在最終段

ganei07/13 18:52記得2003年左右就有pcm2702的pcb可以玩,2.0 非同步的

ganei07/13 18:52audio 介面出來要到2010去了(XMOS方案),有本事拿Cypress

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

elguapo07/13 18:53更正: Mac A

※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 19:33:15

greg757507/13 19:40古早拿270x 蝦機八搭棚的一堆啊,好玩

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

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

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

內文有說排除,類比串擾,這邊講的是系統理論,CLK一樣DATA一樣就是一樣,但這裡沒 講類比串擾哦,系統隔絕能力,noise 樣態大小這些都是可能不一樣的點 而且chip 都還有PVT的偏移,要計較的話多的是可以計較的

※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 19:55:39 ※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 20:33:23

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

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

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

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

dancehotdog: 後就不見得是特定族群喜歡的 07/13 22:03

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

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

拉很高那有沒有代價,這個代價也可能影響其他電器特性

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

並沒有很簡單,這些相容性情況組合變因有無數種,不能感覺, 如果要這樣算今天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起來 電器特性的改變就是系統規格可以接受的誤差

yys31007/13 23:09有哪台DAC隔離能力高到無敵了嗎?

icekiba: 高價的隔離能力搞不好還很差XD 07/13 23:15

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

隔離能力是chip隔離還是PCB技巧?還是chip間相容性? 切的很乾淨是多乾淨?有沒有代價或副作用? 或是加強LDO?今天拉高PSRR,瞬間抽電的恢復能力變差就是代價, 電路的東西要取捨的東西太多不是非黑即白沒有無敵的那種事

※ 編輯: bt092001 (125.228.98.41 臺灣), 07/14/2023 00:06:21 ※ 編輯: bt092001 (125.228.98.41 臺灣), 07/14/2023 00:11:58 ※ 編輯: bt092001 (125.228.98.41 臺灣), 07/14/2023 00:13:32 ※ 編輯: bt092001 (125.228.98.41 臺灣), 07/14/2023 00:20:25

louis040707/14 00:52覺得這篇原Po講得很好xddd

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

elguapo07/14 02:36統時鐘校正,不正是呼應您說的「要合規走最高規」?

您誤會這邊講的合規跟走最高規的意思, 隨便指一個案例,能走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不影響聲音品質阿

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

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

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

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

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

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

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

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

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 08:48:55 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 08:54:22 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 08:57:35 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:00:03 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:08:24

elguapo07/14 09:10行動無線通信,手機基本上也是一個DAC(最後要變成聲音)

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

elguapo07/14 09:10的事,對吧?

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:13:12

應用不同啊,這裡是音響hiend 相關應用, 你今天聽音響會在乎聲音早1ms或晚1ms發出?還是比較在乎聲音品質? 而且serdes 的原理使用本來就是會切斷前面的clk用自己的clk 對於DAC的系統的角度,前面不論花多少功夫再準再校正,DAC只會認為他是一個延遲時間 。

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:16:30 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:20:14 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 09:33:28

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

kshieh07/14 09:36的重組packetized pcm data,接收端de-packetized後,就無

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

kshieh07/14 09:36出就可以了

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

elguapo07/14 10:07的media profile),而AoIP也有 Hi-end 產品(Merging NA

elguapo07/14 10:07DAC)。若照您的意思AES67的同步也是沒意義的,反正DAC

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

elguapo07/14 10:07

假如你是平行三部一樣的DAC,三部的jitter 量是一樣的,如果前端過的PHY或是cable 不同,這三部的延遲會不同,所以你要的應用是多部平行的DAC,同時發訊號? 這樣理解你要的應用對嗎? 如果是這樣的應用就是讓DAC吃同一個外接或是本地CLK且skew一致並且這幾部的DATA sk ew要在一個UI內,這樣就隔絕前端CLK並且DAC同時輸出 ASE67只能同步DATA skew到DA家門口

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:30:02 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:33:08 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:38:02

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

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

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

kshieh07/14 10:46想得太廣了些

不確定原原po要的應用是不是多部DAC同時播放,感覺上是那個意思,但是其實那樣也 跟AES67無關,因為串列傳輸會隔掉上一級clk

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:47:49 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:49:21 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:49:43 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:54:14 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 10:58:13 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 11:10:36

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

kshieh07/14 11:06s a professional protocol called RAVENNA to manage the

kshieh07/14 11:06 data transfer and ensures a very high level of data i

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

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

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

elguapo07/14 11:11有個軟體叫做「Dante Via」,可以把另一台電腦的 USB DAC

elguapo07/14 11:11 變為 Dante network 的一部分。您可以拿這個東西實作:A

elguapo07/14 11:11電腦Dante,B 和 C 電腦Dante Via,B 和 C 電腦各掛一個

elguapo07/14 11:11不同品牌的 USB DAC,然後 A 電腦將 B 和 C 的 USB DAC

elguapo07/14 11:11 作為 4ch 輸出(就當作做 2.2 分頻),請問主時鐘會是

elguapo07/14 11:11哪一台電腦?那台電腦的時鐘來源又是什麼?

elguapo07/14 11:13@kshieh Ravenna是AoIP的一種,符合AES67規範。

我大致理解e大的想法但跨越PHY不是所謂的主時鐘概念,都是使用本地CLK,其他都是成 串封包內含DATA以及CLK的資料編碼,但不是用這個CLK在傳,走乙台網路就是用乙台網路 發射速度,封包內涵音訊的資料跟clk rate資料這些都被視為DATA,你所謂的主時鐘同步 對於系統只是同步DATA skew,而不是同步DAC CLK,這些DATA skew只要在一個UI內,兩 部DAC就不會看錯資料

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 11:34:01 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 11:38:18 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 11:41:17

djboy07/14 11:58BT大辛苦了

elguapo07/14 11:59https://i.imgur.com/FjcZmIN.jpg

elguapo07/14 12:00webinar 資料,描述是 local clock 被主鐘同步

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

elguapo07/14 12:02對不起更正,”precisely”

elguapo07/14 12:08slide 是指出 local clock 是 GMC 的 copy*

這時文件定義的問題對於你只看dante 來說是,但是對於以最後一級為DA全系統來說的物 理意義不是

※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:36:26 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:37:20

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

kshieh07/14 15:17ee run,alignment of streams是1/2 sample time 。以48kH

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

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

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

kshieh07/14 15:17題。

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

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

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