: 推 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: 更正: Mac A 07/13 18:53
就我所知，Vitual interfac （自己）沒有音頻時鐘
Vitual interface 可以不需要依存音頻時鐘，因為處理的只是數據流
在這我又要截一大段 Roon 討論串中的對話救援
※
DAC 只能從其本地緩衝區中提取數據，因此它不關心上游的連接。核心只能將數據放入其
本地緩衝區，因為它不關心下游的連接。
RAAT 管理兩者之間的數據傳輸，為了確保所有位元能夠完整地從核心傳送到DAC，它使用
網絡本身提供的較低層級功能來確保數據的完整性。如果丟失一個數據包，將發送一個新
的數據包並按正確順序放入緩衝區。如果數據包損壞，也是同樣的處理方式。在大多數情
況下，緩衝區足夠大，以使這個錯誤修復過程能夠在DAC耗盡數據或核心填滿其緩衝區之
前進行。
請記住，我在這裡非常謹慎地使用「數據」這個詞，因為這是音樂此時的形式。它是正在
播放的文件的位元串流。這是一個異步過程，對DAC的模擬輸出沒有影響。RAAT（以及網
絡堆棧）在核心和終端之間促成了一個非常互動的對話。它們確保文件（不超過緩衝區的
大小）從核心複製到終端。
……
這是一個異步過程。根據定義，傳輸過程的時序（時鐘同步）與解碼過程完全獨立。緩衝
區的填充和清空速率會變化，但只要DAC的緩衝區中有足夠的數據，播放將會持續可靠進
行。
這裡的關鍵是區分數據和信號的區別。正在播放的文件在其位元以實時方式通過DAC進行
轉換之前，不會變成信號。在它們從DAC（或終端）的本地緩衝區中提取之前，這些位元
與用於文檔、圖像甚至本帖中的位元沒有區別。
我理解發燒友不斷嘗試「改進」事物的渴望，這種行為實際上是這個愛好的基礎。在過去
，當大多數概念與某些物理事物相關並且變化不僅容易展示，而且還可以通過一些邏輯解
釋來支持時，這種改進更容易實現。然而，數字世界並非如此，因為其中許多概念與直覺
相悖，解釋也更加複雜。
※
雖然 Vitual interfac 跟 Roon RAAT 有些差異，但本質上是相同的
當 Vitual I/F 的輸出入是同 sample rate 時，Vitual I/F 的做用只是傳遞數據
音頻數據應該被直接 pass through
當輸出輸入是不同 sample rate 時，會需要 SRC，但有兩種選擇
●其一是 SRC 採樣率鎖死，如 44100 Hz 轉 96000 Hz 或等倍的 Oversampling
前端如果是 foobar 之類的 player、不會有時鐘問題，就單純的送資料填 buffer
但輸入與輸出端若有實體時鐘差異會出現 Drift
我們的默認實現使用一種稱為“填充”和“刪除”樣本的技術
基本上是插入或刪除單個樣本。
粗暴有效的解法，有可能出現爆裂聲:D
●另一種就是用 Async SRC、也就是 Drift Correction，但 ASRC 開銷大
Drift Correction 的過程一般 Vitual interfac 也是沒時鐘
因為前後端的進出的樣本數差異，是前後端硬體的時鐘差異造成的
視其中一方為主就解決了，依方向選好主角、另一個配合主角
至少我沒看過有實踐把系統主時鐘拿進來湊一腳，讓系統主時鐘當主角的狀況
但我猜這也是 e大您的理想
※
我上一篇推文中就有提過
Mac 的 Drift Correction 我上面貼的那篇也有提到
彌補的也只是 Audio device 間的 Audio clock 差異
跟 System clock 無關
就像這頁裏的第一個圖
https://support.apple.com/en-us/HT202000
Clock Source 能選系統時鐘嗎？只有 Audio device 能選不是嗎
從 e大當時的回答我就知道在段您想歪了

辛苦了！

我都用notepad開wav檔來看，領悟音樂之美

您描述的內容，前題是電腦的系統時鐘是穩定的。我在這一大串的討論應該有提過，系統時鐘並不穩定，說開大buffer就能解決只是逃避問題。若因作業需求必須分秒必爭，將buffer縮小達成低latency，例如兩地區即時收音、混音並即時播放，您會怎麼做？（AES67 最大的應用是跨子網域做I/O。）

做Switch的打3天72小時不能掉包，DUT的X'tal也才+-50ppm而已，clock精度啥的其實還好，運作機制夠強就不是大問題

問：AES67 在跨網域、跨國際運用時中間的所有 ISP 網通設備時鐘精度會是 10ns 級或是 >100ns AES67 為什麼能正常工作？答：依據GMC traceability 以及 HW timestamp 。@ganei 同步乙太網路對交換器要求蠻高的，可以當 IEEE1588 BC 的交換器很貴…

我覺得e大要先看一下serial link and physical layer ，感覺e大還沒有這兩種概念

IEEE1588 BC 交換器也僅是L3。RTP stream 會把 Ref CLK資訊包含在內。每個 stream 裡面的每個 packets 都打上時戳以便下一個節點recover clock。@bt092001 我手上有 AES3 AES5 AES11 規範的完整版，也有買 DAC 設計相關的叢書來念。或許我真的不是讀書的料，若您認為我讀的不夠或是概念不足，可否建議我書單？

我覺得不是書讀的不夠，而是有點搞混，我先想請教如果今天，您今天一直強調主時鐘同步，再您的觀念中這個主時鐘是如何傳遞給下一級？

就如同我在您的post的問題，手機即是ADC也同是DAC，為何ITU-T仍要指出5G network的同步問題及必須手段？您一直是用DAC PHY 去理解整個問題，並不認為同步傳輸是有意義的。我個人不會去challenge個人想法，我也會同意您的見解。但對於我的知識不足的部分，也請建議我書單，我會去讀。

就以這個同步的主時鐘來說好了，您認為怎麼轉傳到下一級？如果以RJ45或是USB傳送，並沒有CLK 的IO接口，後級如何知道這個CLK?

「此同步非彼同步」：都是IEEE1588 implementation 請問有何不同？「後級如何知道這個CLK」：SDP 會標註 Ref clock 給後一級；若沒有 GMC 則會用本身的 system clock 為 Ref clock。「因為這個同步是應用同步，而非傳輸同步」：AoIP 是同步傳輸的一種。

好，所以後一級只是知道前一級的資訊，如果後一級用自己的system CLK 去敲，是不是跟前一級的CLK不phase alignment？

「因為以封包為基礎的網路傳輸過程，沒有同步這回事」：SyncE 就是在改正這件事。@bt092001 後一級會變 slave

所以我先當頻率一樣，後一級的CLK 波形長相是不是跟前一級無關？

@bt092001 我想我已經表達過，您是認為DAC PHY可解決所有問題的人，前端長再醜都能搞定。我同意，不爭執。我個人剛好是站在對面，認為DAC就是要聽中央指揮的東西，不聽指揮就抱歉移除，聲音再好，不合群的也只能請離。應該沒有人說DAC PHY是永遠不能改動或改進去配合時鐘同步吧？

爆音或靜默？

E大的想法偏向parallels bus精神，但目前市售主流chip還是異步CLK

「爆音或靜默？」：我熟悉的器材在偵測到 sample rate change 或是 GMC change 是自動靜默，對齊了之後再發聲。「這並不需要超精準時鐘」：AES67主時鐘規範同AES11，必須達 Grade 1。Grade 1「看似」不精準，但現有器材放眼望去還真的沒幾款。Sample rate change from 48KHz to 96KHz 並不是 drift correction 保護的範圍；GMC change 若兩個 GMC 的 ppm 差異不大（例如兩個 Grade 1 GPS PTP GMC）那麼頂多是顯示重新鎖定但音頻不會靜默（這部分是 SMPTE ST2110 的 redundancy 會講到的）。如果是 Grade 1 降級到另一個 Grade2 的 GMC 就可能發生重新鎖定過久而必須靜默。順帶一提，若是採 SMPTE 規範，那麼全部器材都要達 < +-5ppm 精度，比 AES 規範還嚴苛。「好像不用壓到 10ns 的精度」：同意，確實是不用。新收的網卡有這個能力也很穩定，是意外收穫。「純粹是個人想像」：所以沒有在用AES67的您是不是也用想像的方式否定這些使用心得？若我的假設是被您認定不科學且無根據，我ok。就此打住，不再回覆。

推O大

建議e大看一下 Ethernet or usb or hdmi physical layer block diagram 而且最好能知道那些電路作用，還有那些IO到底傳什麼的定義，大概就能發現不合理處只要知道那些block電路用途跟IO傳了什麼就好

無論你用掛號印出來還是PDF寄email，內容沒差sampling rate只是讀稿機的語速而已跟想像的不一樣，表示想像力有問題ww

那foobar 16bit時可以選dither是不該選嗎？

我一開始就知道他想歪啊 XDDDdither的話，聽無損沒差，聽有損的可以開有損的試過聽了沒差的話就不用開。有損的格式會有奇奇怪怪的模型壓縮，開了"可能"會好聽windows還會很貼心的幫你切掉peak。系統底層的切

想借這篇問大大們 我在VST軟體上(以SIR3為例)調整音量的動作會影響檔案的bit depth嗎? 等等附圖" target="_blank" rel="noreferrer noopener nofollow">

紅圈部分感謝O大解惑~立刻掛上去foobar2000 2.0來串看看~