PTT數位生活區 / Audiophile (電腦喇叭 音響系統)

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

看板Audiophile (電腦喇叭 音響系統)作者 (一條魚)時間1年前 (2023/07/13 16:33), 1年前編輯推噓20(20推 0噓 77→)
留言97則, 13人參與, 1年前最新討論串3/5 (看更多)
原文恕刪 以下簡易解釋優化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 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1689237197.A.AFE.html ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:37 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 16:35:52
推
07/13 16:38, 1年前 , 1F
大腸麵
07/13 16:38, 1F
→
07/13 16:40, 1年前 , 2F
多加香菜
07/13 16:40, 2F
推
07/13 17:03, 1年前 , 3F
可能要在結論區加一句：「系統的GLOBAL CLOCK沒有對準，
07/13 17:03, 3F
→
07/13 17:04, 1年前 , 4F
可視為前端有狀況，但是均己被DAC後端解決掉」
07/13 17:04, 4F
→
07/13 17:05, 1年前 , 5F
這樣子，原原PO才看的懂
07/13 17:05, 5F
感謝補充，的確是這樣理解，如果狀況大到PHY看不懂，資料是送不出來的 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:12:19
推
07/13 17:16, 1年前 , 6F
原原po有說到在USB DAC做resampling時需要準確的時間，才
07/13 17:16, 6F
→
07/13 17:16, 1年前 , 7F
會算(interpolate)出正確的結果？
07/13 17:16, 7F
→
, , 8F
更正：是電腦做resampling
07/13 17:18 這樣意義不大，因為聽到的聲音的CLK是DAC 本地CLK在送，電腦端的東西也只是被DIgita lPHY存起來視為系統latency 而已
推
07/13 17:19, 1年前 , 9F
目前主流就是傳輸為異步，明示兩端被不同步的 buffer 分隔
07/13 17:19, 9F
→
07/13 17:19, 1年前 , 10F
而 DAC 還是工在同步模式，所以 DAC 依賴的時鐘源很重要
07/13 17:19, 10F
推
07/13 17:27, 1年前 , 11F
dpc latency 大到讓音樂起肖的狀況也蠻常發生(
07/13 17:27, 11F
推
07/13 17:28, 1年前 , 12F
封包，你退下。
07/13 17:28, 12F
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:36:25
推
07/13 17:37, 1年前 , 13F
所以為什麼之前很多人玩PC訊源都是先幹了p/c state這類
07/13 17:37, 13F
→
07/13 17:37, 1年前 , 14F
另外電腦算什麼都不用準確的時間 是要準確的clk,連時間都
07/13 17:37, 14F
→
07/13 17:37, 1年前 , 15F
是以clk為基礎算出來的. 電腦內有時間觀念的硬體大概RTC吧
07/13 17:37, 15F
→
07/13 18:08, 1年前 , 16F
玩過走USB 1.x的 DAC就知道DAC起乩其實也還好，重插RESET一
07/13 18:08, 16F
→
07/13 18:08, 1年前 , 17F
下而已(重新同步)，頂多一直斷電重開有點煩，等哪天受不了
07/13 18:08, 17F
→
07/13 18:08, 1年前 , 18F
自然會換走2.0非同步的新機... (不便引發的購物衝動
07/13 18:08, 18F
推
07/13 18:10, 1年前 , 19F
1.1沒幾年就2.0化了
07/13 18:10, 19F
推
07/13 18:51, 1年前 , 20F
感謝解說。但我的point真的不是DAC的design問題。場景：M
07/13 18:51, 20F
→
07/13 18:51, 1年前 , 21F
ac A 用 Dante 連 Mac B，Mac B 用 internal looping 將
07/13 18:51, 21F
→
07/13 18:51, 1年前 , 22F
音訊轉給 USB DAC。Dante 和 internal looping 是虛擬介
07/13 18:51, 22F
→
07/13 18:51, 1年前 , 23F
面。請問音訊資料傳遞時，max A -> Mac B 傳 Dante 時誰
07/13 18:51, 23F
→
07/13 18:51, 1年前 , 24F
是主鐘？到了 Mac B，Dante 借 internal looping 到 USB
07/13 18:51, 24F
→
07/13 18:51, 1年前 , 25F
DAC ，這時的時鐘如何轉換？
07/13 18:51, 25F
坦白說只要合規前端並不重要， 因為到DAC前可能過了無數個PHY，他們之間只要DATA對， 其他firmware,software,hardware 之間 如何handshake 轉了什麼格式的資料或是時鐘，只要合規走最高規互相能看懂就好， 但詳細還要去看各個介面的spec 。 最終性能決定還是在最終段
→
07/13 18:52, 1年前 , 26F
記得2003年左右就有pcm2702的pcb可以玩，2.0 非同步的
07/13 18:52, 26F
→
07/13 18:52, 1年前 , 27F
audio 介面出來要到2010去了(XMOS方案)，有本事拿Cypress
07/13 18:52, 27F
→
07/13 18:52, 1年前 , 28F
晶片或FPGA自幹的論外，這大概比日本製壓縮機還稀少
07/13 18:52, 28F
→
07/13 18:53, 1年前 , 29F
更正: Mac A
07/13 18:53, 29F
※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 19:33:15
→
07/13 19:40, 1年前 , 30F
古早拿270x 蝦機八搭棚的一堆啊，好玩
07/13 19:40, 30F
→
07/13 19:41, 1年前 , 31F
xmos 粗乃還是有一大堆receiver活得好好的(
07/13 19:41, 31F
→
07/13 19:42, 1年前 , 32F
usb剛粗乃的時候cs8xxx這些轉IIS的很熱門
07/13 19:42, 32F
→
07/13 19:50, 1年前 , 33F
這種說法已經十幾年 還是沒解釋為什麼電腦不同聲音不同
07/13 19:50, 33F
內文有說排除，類比串擾，這邊講的是系統理論，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
還有 28 則推文
還有 8 段內文
→
07/14 10:07, 1年前 , 62F
的media profile），而AoIP也有 Hi-end 產品（Merging NA
07/14 10:07, 62F
→
07/14 10:07, 1年前 , 63F
DAC）。若照您的意思AES67的同步也是沒意義的，反正DAC
07/14 10:07, 63F
→
07/14 10:07, 1年前 , 64F
都會修正一切。請問DAC會處理兩三個DAC之間的時間差異嗎
07/14 10:07, 64F
→
07/14 10:07, 1年前 , 65F
？
07/14 10:07, 65F
假如你是平行三部一樣的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
推
07/14 10:43, 1年前 , 66F
傳遞延遲就是在網路容量規畫時要考慮的，再來就是把QoS設
07/14 10:43, 66F
→
07/14 10:43, 1年前 , 67F
好。pcm資料離開AES67網路後，DAC就是單純撥放而已
07/14 10:43, 67F
→
07/14 10:46, 1年前 , 68F
AES67的時間同步是重中之重。只是你可能吧AES67的工作範圍
07/14 10:46, 68F
→
07/14 10:46, 1年前 , 69F
想得太廣了些
07/14 10:46, 69F
不確定原原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
推
07/14 11:06, 1年前 , 70F
看了一下Merging+NADAC的產品說明，他們有提到一句"it use
07/14 11:06, 70F
→
07/14 11:06, 1年前 , 71F
s a professional protocol called RAVENNA to manage the
07/14 11:06, 71F
→
07/14 11:06, 1年前 , 72F
data transfer and ensures a very high level of data i
07/14 11:06, 72F
→
07/14 11:07, 1年前 , 73F
ntegrity and a timing accuracy of 1 nanosecond"看起來
07/14 11:07, 73F
→
07/14 11:07, 1年前 , 74F
是很優是吧？可是假如不走網路用同軸線直連(這台DAC也能直
07/14 11:07, 74F
→
07/14 11:07, 1年前 , 75F
連)的話，根本就沒有這個timing問題 哈
07/14 11:07, 75F
→
07/14 11:11, 1年前 , 76F
有個軟體叫做「Dante Via」，可以把另一台電腦的 USB DAC
07/14 11:11, 76F
→
07/14 11:11, 1年前 , 77F
變為 Dante network 的一部分。您可以拿這個東西實作：A
07/14 11:11, 77F
→
07/14 11:11, 1年前 , 78F
電腦Dante，B 和 C 電腦Dante Via，B 和 C 電腦各掛一個
07/14 11:11, 78F
→
07/14 11:11, 1年前 , 79F
不同品牌的 USB DAC，然後 A 電腦將 B 和 C 的 USB DAC
07/14 11:11, 79F
→
07/14 11:11, 1年前 , 80F
作為 4ch 輸出（就當作做 2.2 分頻），請問主時鐘會是
07/14 11:11, 80F
→
07/14 11:11, 1年前 , 81F
哪一台電腦？那台電腦的時鐘來源又是什麼？
07/14 11:11, 81F
→
07/14 11:13, 1年前 , 82F
@kshieh Ravenna是AoIP的一種，符合AES67規範。
07/14 11:13, 82F
我大致理解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
推
07/14 11:58, 1年前 , 83F
BT大辛苦了
07/14 11:58, 83F
→
07/14 11:59, 1年前 , 84F
07/14 11:59, 84F
→
07/14 12:00, 1年前 , 85F
webinar 資料，描述是 local clock 被主鐘同步
07/14 12:00, 85F
→
07/14 12:01, 1年前 , 86F
Fully 這個辭意應該不是只有 skew
07/14 12:01, 86F
→
07/14 12:02, 1年前 , 87F
對不起更正，”precisely”
07/14 12:02, 87F
→
07/14 12:08, 1年前 , 88F
slide 是指出 local clock 是 GMC 的 copy*
07/14 12:08, 88F
這時文件定義的問題對於你只看dante 來說是，但是對於以最後一級為DA全系統來說的物 理意義不是 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:36:26 ※ 編輯: bt092001 (223.137.239.156 臺灣), 07/14/2023 12:37:20
推
07/14 15:17, 1年前 , 89F
我再讀了一遍e大提供的webinar投影片，的確是有提到若是fr
07/14 15:17, 89F
→
07/14 15:17, 1年前 , 90F
ee run，alignment of streams是1/2 sample time 。以48kH
07/14 15:17, 90F
→
07/14 15:17, 1年前 , 91F
z來算，約是10us。若pcm下i2s時能控制BCLK的起始時間，的
07/14 15:17, 91F
→
07/14 15:17, 1年前 , 92F
確能做到更精準的multi stream alignment… 只是一般家用
07/14 15:17, 92F
→
07/14 15:17, 1年前 , 93F
系統都是在傳mux好的雙/多聲道訊號，自然沒有alignment問
07/14 15:17, 93F
→
07/14 15:17, 1年前 , 94F
題。
07/14 15:17, 94F
推
07/14 15:39, 1年前 , 95F
我是覺得 不是大型場館的應用 明明可以有更可靠的方法 卻
07/14 15:39, 95F
→
07/14 15:39, 1年前 , 96F
硬要跑進水(ip network)裡，用來奧林匹克等級的泳技，結果
07/14 15:39, 96F
→
07/14 15:39, 1年前 , 97F
速度還是輸給陸地慢跑的阿伯…
07/14 15:39, 97F
‣ 更多 bt092001 的文章
文章代碼(AID): #1ahxRDh- (Audiophile)
Audiophile 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 bt092001 的文章
文章代碼(AID): #1ahxRDh- (Audiophile)