推 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
感謝補充，的確是這樣理解，如果狀況大到PHY看不懂，資料是送不出來的
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:12:19
推 kshieh: 原原po有說到在USB DAC做resampling時需要準確的時間，才07/13 17:16
→ kshieh: 會算(interpolate)出正確的結果？ 07/13 17:16
→ kshieh: 更正：是電腦做resampling
07/13 17:18
這樣意義不大，因為聽到的聲音的CLK是DAC 本地CLK在送，電腦端的東西也只是被DIgita
lPHY存起來視為系統latency 而已
推 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
※ 編輯: bt092001 (223.137.239.156 臺灣), 07/13/2023 17:36:25
推 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
坦白說只要合規前端並不重要，
因為到DAC前可能過了無數個PHY，他們之間只要DATA對，
其他firmware,software,hardware 之間
如何handshake 轉了什麼格式的資料或是時鐘，只要合規走最高規互相能看懂就好，
但詳細還要去看各個介面的spec 。
最終性能決定還是在最終段
→ 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
※ 編輯: bt092001 (125.228.98.41 臺灣), 07/13/2023 19:33:15
→ 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
內文有說排除，類比串擾，這邊講的是系統理論，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也不是吃素，能做 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
→ dancehotdog: 後就不見得是特定族群喜歡的 07/13 22:03
→ yamatai: 類比串擾 noise 樣態 也只是你的假設阿07/13 23:03
→ yamatai: 如果這麼簡單那 DAC 把隔絕能力拉高不就無敵了07/13 23:04
拉很高那有沒有代價，這個代價也可能影響其他電器特性
→ yamatai: 問題就是現在沒有任何 DAC 可以改變電腦不同聲音不同現象 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隔離能力高到無敵了嗎？ 07/13 23:09
推 icekiba: 高價的隔離能力搞不好還很差XD 07/13 23:15
→ yamatai: 沒有吧 很強調技術的廠牌隔離能力都很高了吧 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講得很好xddd07/14 00:52
→ elguapo: 音頻資料在使用/傳遞過程若有吃到系統時鐘的部分，將系07/14 02:36
→ elguapo: 統時鐘校正，不正是呼應您說的「要合規走最高規」？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: 電源線沒差的話，設備就不用買雙屏蔽超級小黑線了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
※ 編輯: 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（最後要變成聲音）07/14 09:10
→ elguapo: ，按照您的意思，ITU-T對5G通信網路要求同步是沒有意義07/14 09:10
→ elguapo: 的事，對吧？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的坑了，時間同步是為了接收端正確 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
假如你是平行三部一樣的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設07/14 10:43
→ kshieh: 好。pcm資料離開AES67網路後，DAC就是單純撥放而已07/14 10:43
→ kshieh: AES67的時間同步是重中之重。只是你可能吧AES67的工作範圍07/14 10:46
→ kshieh: 想得太廣了些07/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
推 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
我大致理解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大辛苦了07/14 11:58
→ 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
這時文件定義的問題對於你只看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投影片，的確是有提到若是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