回看板
Disp BBS
作者 bt092001 (一條魚)
標題 Re: [心得] 運用 Chrony 對時工具提升音訊品質
時間 Thu Jul 13 16:33:15 2023

原文恕刪

以下簡易解釋優化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
[圖]
 
[圖]


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

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.239.156 (臺灣)
※ 作者: bt092001 2023-07-13 16:33:15
※ 文章代碼(AID): #1ahxRDh- (Audiophile)
※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689237197.A.AFE.html
※ 同主題文章:
[心得] 運用 Chrony 對時工具提升音訊品質
07-10 21:09 elguapo
Re: [心得] 運用 Chrony 對時工具提升音訊品質
07-11 20:49 Oswyn
Re: [心得] 運用 Chrony 對時工具提升音訊品質
07-13 16:33 bt092001
Re: [心得] 運用 Chrony 對時工具提升音訊品質
07-13 20:20 Oswyn
Re: [心得] 運用 Chrony 對時工具提升音訊品質
07-15 00:01 sunyanwen
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:37
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:52
推 icekiba: 大腸麵1F 07/13 16:38
→ evadodoya: 多加香菜2F 07/13 16:40
推 djboy: 可能要在結論區加一句：「系統的GLOBAL CLOCK沒有對準，
可視為前端有狀況，但是均己被DAC後端解決掉」
這樣子，原原PO才看的懂3F 07/13 17:03
感謝補充，的確是這樣理解，如果狀況大到PHY看不懂，資料是送不出來的
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:12:19
推 kshieh: 原原po有說到在USB DAC做resampling時需要準確的時間，才會算(interpolate)出正確的結果？
更正：是電腦做resampling
6F 07/13 17:16
07/13 17:18
這樣意義不大，因為聽到的聲音的CLK是DAC 本地CLK在送，電腦端的東西也只是被DIgita
lPHY存起來視為系統latency 而已
推 Oswyn: 目前主流就是傳輸為異步，明示兩端被不同步的 buffer 分隔而 DAC 還是工在同步模式，所以 DAC 依賴的時鐘源很重要9F 07/13 17:19
推 greg7575: dpc latency 大到讓音樂起肖的狀況也蠻常發生(
封包，你退下。11F 07/13 17:27
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:36:25
推 comipa: 所以為什麼之前很多人玩PC訊源都是先幹了p/c state這類
另外電腦算什麼都不用準確的時間 是要準確的clk,連時間都是以clk為基礎算出來的. 電腦內有時間觀念的硬體大概RTC吧13F 07/13 17:37
→ ganei: 玩過走USB 1.x的 DAC就知道DAC起乩其實也還好，重插RESET一下而已(重新同步)，頂多一直斷電重開有點煩，等哪天受不了自然會換走2.0非同步的新機...  (不便引發的購物衝動16F 07/13 18:08
推 icekiba: 1.1沒幾年就2.0化了19F 07/13 18:10
推 elguapo: 感謝解說。但我的point真的不是DAC的design問題。場景：Mac A 用 Dante 連 Mac B，Mac B 用 internal looping 將音訊轉給 USB DAC。Dante 和 internal looping 是虛擬介面。請問音訊資料傳遞時，max A -> Mac B 傳 Dante 時誰是主鐘？到了 Mac B，Dante 借 internal looping 到 USB DAC ，這時的時鐘如何轉換？20F 07/13 18:51
坦白說只要合規前端並不重要，
因為到DAC前可能過了無數個PHY，他們之間只要DATA對，
其他firmware,software,hardware 之間
如何handshake 轉了什麼格式的資料或是時鐘，只要合規走最高規互相能看懂就好，
但詳細還要去看各個介面的spec 。
最終性能決定還是在最終段
→ ganei: 記得2003年左右就有pcm2702的pcb可以玩，2.0 非同步的
audio 介面出來要到2010去了(XMOS方案)，有本事拿Cypress晶片或FPGA自幹的論外，這大概比日本製壓縮機還稀少26F 07/13 18:52
→ elguapo: 更正: Mac A29F 07/13 18:53
※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 19:33:15
→ greg7575: 古早拿270x 蝦機八搭棚的一堆啊，好玩
xmos 粗乃還是有一大堆receiver活得好好的(
usb剛粗乃的時候cs8xxx這些轉IIS的很熱門30F 07/13 19:40
→ yamatai: 這種說法已經十幾年 還是沒解釋為什麼電腦不同聲音不同33F 07/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
推 djboy: 其實，現在都2023年了，AKM/ESS的高薪RD也不是吃素，能做能改的應該都全下了(除了COST DOWN版本，這也是盡力COST
DOWN)。DAC IC 大概也就如此，除非有天才或是架構性的突破34F 07/13 21:49
推 dancehotdog: 產品會往cp值發展 不太會只考慮音質 就像3C一樣 到最後就不見得是特定族群喜歡的                        37F 07/13 22:03
→ yamatai: 類比串擾 noise 樣態 也只是你的假設阿
如果這麼簡單那 DAC 把隔絕能力拉高不就無敵了39F 07/13 23:03
拉很高那有沒有代價，這個代價也可能影響其他電器特性
→ yamatai: 問題就是現在沒有任何 DAC 可以改變電腦不同聲音不同現象41F 07/13 23:05
並沒有很簡單，這些相容性情況組合變因有無數種，不能感覺，
如果要這樣算今天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起來
電器特性的改變就是系統規格可以接受的誤差
→ yys310: 有哪台DAC隔離能力高到無敵了嗎？42F 07/13 23:09
推 icekiba: 高價的隔離能力搞不好還很差XD                          43F 07/13 23:15
→ yamatai: 沒有吧 很強調技術的廠牌隔離能力都很高了吧44F 07/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
推 louis0407: 覺得這篇原Po講得很好xddd45F 07/14 00:52
→ elguapo: 音頻資料在使用/傳遞過程若有吃到系統時鐘的部分，將系統時鐘校正，不正是呼應您說的「要合規走最高規」？46F 07/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不影響聲音品質阿

推 greg7575: 電源線沒差的話，設備就不用買雙屏蔽超級小黑線了
整台電腦都換掉，產生的改變也當然會存在
即便是流水生產的，以高頻探頭為例。還是要各別校對
只是現在沒生產出拉普拉斯的妖怪，沒辦法確定一切
無論再怎麼電路隔離，元件以及機箱內的環境都會有噪
噪除了電路，還有元件工作電磁波反射、外在電磁波引入跟夸父追日一樣，追不到。追的過程又產生新的問題
版子上面元件間距，會不會產生渦流，一堆鬼故事48F 07/14 07:20
※ 編輯: 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
→ elguapo: 行動無線通信，手機基本上也是一個DAC（最後要變成聲音），按照您的意思，ITU-T對5G通信網路要求同步是沒有意義的事，對吧？56F 07/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
推 kshieh: 我想e大應該是陷在AoIP的坑了，時間同步是為了接收端正確的重組packetized pcm data，接收端de-packetized後，就無需那個時間資訊，直接把pcm stream丟進去i2s audio i/f輸出就可以了59F 07/14 09:36
→ elguapo: 應用沒有不同。AoIP 本質就是同步網路（用的是IEEE1588的media profile），而AoIP也有 Hi-end 產品（Merging NADAC）。若照您的意思AES67的同步也是沒意義的，反正DAC都會修正一切。請問DAC會處理兩三個DAC之間的時間差異嗎？63F 07/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
推 kshieh: 傳遞延遲就是在網路容量規畫時要考慮的，再來就是把QoS設好。pcm資料離開AES67網路後，DAC就是單純撥放而已
AES67的時間同步是重中之重。只是你可能吧AES67的工作範圍想得太廣了些68F 07/14 10:43
不確定原原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
推 kshieh: 看了一下Merging+NADAC的產品說明，他們有提到一句"it uses a professional protocol called RAVENNA to manage the data transfer and ensures a very high level of data integrity and a timing accuracy of 1 nanosecond"看起來是很優是吧？可是假如不走網路用同軸線直連(這台DAC也能直連)的話，根本就沒有這個timing問題 哈72F 07/14 11:06
→ elguapo: 有個軟體叫做「Dante Via」，可以把另一台電腦的 USB DAC 變為 Dante network 的一部分。您可以拿這個東西實作：A電腦Dante，B 和 C 電腦Dante Via，B 和 C 電腦各掛一個不同品牌的 USB DAC，然後 A 電腦將 B 和 C 的 USB DAC 作為 4ch 輸出（就當作做 2.2 分頻），請問主時鐘會是哪一台電腦？那台電腦的時鐘來源又是什麼？
@kshieh Ravenna是AoIP的一種，符合AES67規範。78F 07/14 11:11
我大致理解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
推 djboy: BT大辛苦了85F 07/14 11:58
→ elguapo: https://i.imgur.com/FjcZmIN.jpg
webinar 資料，描述是 local clock 被主鐘同步
Fully 這個辭意應該不是只有 skew
對不起更正，”precisely”
slide 是指出 local clock 是 GMC 的 copy*86F 07/14 11:59
[圖]
這時文件定義的問題對於你只看dante 來說是，但是對於以最後一級為DA全系統來說的物
理意義不是
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:36:26
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:37:20
推 kshieh: 我再讀了一遍e大提供的webinar投影片，的確是有提到若是free run，alignment of streams是1/2 sample time 。以48kHz來算，約是10us。若pcm下i2s時能控制BCLK的起始時間，的確能做到更精準的multi stream alignment… 只是一般家用系統都是在傳mux好的雙/多聲道訊號，自然沒有alignment問題。
我是覺得 不是大型場館的應用 明明可以有更可靠的方法 卻硬要跑進水(ip network)裡，用來奧林匹克等級的泳技，結果速度還是輸給陸地慢跑的阿伯…91F 07/14 15:17

--

作者 bt092001 的最新發文:
點此顯示更多發文記錄