推 djboy: 辛苦了！ 07/13 20:28
推 greg7575: 我都用notepad開wav檔來看，領悟音樂之美 07/13 20:30
https://i.imgur.com/DhyCdjj.jpg
AV-Audio ASIO bridge
這個就是不支援 Drift Correction 的 Vitual interfac 會碰到的問題
當然文件中的例子是是 48000 vs 44093 Hz
但這也展示了實體時鐘差異引起的狀況
※ 舉個例子
因雙方時鐘差異 src端產生 48001 Hz 的資料流、dst端消耗速率為 47999 Hz
要嗎不理它，每秒有兩個樣本最終會被擠掉
不想插入刪除就要校正，src 的 48001 Hz 配合 dst ASRC 成 47999 Hz
如果用超準系統時間，把 src 的 48001 Hz ASRC 成中原標準 48000 Hz
但現實如 Roon 所說的你管不到下游，所以 dst端的消耗速率還是 47999 Hz
把系統生出來的 new 標準 48000 Hz 資料往 dst 送
dst 每秒還是要丟掉一個樣本，除非 dst 上面有自己的 ASRC 再校正一次
但如果 dst 本來就有 Drift Correction，中間多做一次變校兩次有合理嗎
所以我沒看過有人或產品，在傳輸途中這樣做
※
我又想到另一個不錯的解說
今天我們播放，能從訊源 bit perfect 到 DAC
表示音頻數據在傳輸途中沒有受到任何改變
能 bit perfect 表示沒有發生過任何 DSP、數位音量、DDC
也沒有發生傳輸錯誤、沒發生 Drift、也沒有被 Correction 過
原因為何？
沒有 Drift 是因為路徑上只有一個音頻時鐘，也就是 DAC's
左手只是輔助，中間都只是數據傳輸
→ elguapo: 您描述的內容，前題是電腦的系統時鐘是穩定的。我在這一 07/14 02:10
→ elguapo: 大串的討論應該有提過，系統時鐘並不穩定，說開大buffer 07/14 02:10
→ elguapo: 就能解決只是逃避問題。若因作業需求必須分秒必爭，將buf 07/14 02:10
→ elguapo: fer縮小達成低latency，例如兩地區即時收音、混音並即時 07/14 02:10
→ elguapo: 播放，您會怎麼做？（AES67 最大的應用是跨子網域做I/O。 07/14 02:10
→ elguapo: ） 07/14 02:10
→ elguapo: Virtual interface 若只是處理數據流，那麼為何還要去指 07/14 02:52
→ elguapo: 定 sample rate？ 07/14 02:52
→ elguapo: 「但如果 dst 本來就有 Drift Correction，中間多做一次 07/14 02:59
→ elguapo: 變校兩次有合理嗎」：AoIP 是每個 node 都在做 drift cor 07/14 02:59
→ elguapo: rection。司空見慣。 07/14 02:59
還在不穩定？
1ms 長的 buffer 經不起 幾百ns 的波動？
我都覺得 e大您是不是搞不清楚單位了
我想、AoIP 就算每 node 都在 Drift Correction
也是因為 Drift Correction 的點是各 node 的終端
而不會是在傳輸的節點上 Drift Correction
傳輸應該是 passthrough 的，一直在傳輸過程中橋 payload data
這種操作從沒見過
另外、 e大您可以想想
AES67 在跨網域、跨國際運用時
中間的所有 ISP 網通設備時鐘精度會是 10ns 級或是 >100ns
AES67 為什麼能正常工作？
網通設備的主時鐘，是每台機器上自己的時鐘
→ ganei: 做Switch的打3天72小時不能掉包，DUT的X'tal也才+-50ppm而 07/14 12:35
→ ganei: 已，clock精度啥的其實還好，運作機制夠強就不是大問題 07/14 12:35
→ elguapo: 問：AES67 在跨網域、跨國際運用時中間的所有 ISP 網通設 07/14 14:12
→ elguapo: 備時鐘精度會是 10ns 級或是 >100ns AES67 為什麼能正常 07/14 14:12
→ elguapo: 工作？答：依據GMC traceability 以及 HW timestamp 。 07/14 14:12
→ elguapo: @ganei 同步乙太網路對交換器要求蠻高的，可以當 IEEE158 07/14 14:14
→ elguapo: 8 BC 的交換器很貴… 07/14 14:14
No，這些設備都是異步它們不關心其它人的時間是幾點
合於規範就好，一如 Roon 所說
AES67 是 layer 3 的擴充
就像 e大PO的圖 https://i.imgur.com/FjcZmIN.jpg
上面明示了 Media clock
GM 是為了媒體同步而存在的參考時鐘
回到 Roon討論串中，兩種 clock
您必需分清楚各 clock 在不同場合、位置的不同需求與功能
這個 Media clock 明顯不是為了 Physical layer 而生出來的東西
而是為了更後端的應用，媒體同步所打上的時戳
這東西應該是包在封包內的同步「資料」
而非 Physical 運作中會用到的東西
→ elguapo: 「這些設備都是異步它們不關心其它人的時間是幾點」No。I 07/14 14:36
→ elguapo: EEE1588需要BC or TC能力的交換器。BC能力的交換器是同步 07/14 14:36
→ elguapo: 交換，本身即能為PTP GMC，每個port都會關心收發的時戳； 07/14 14:36
→ elguapo: TC交換器便宜很多，雖然無法當GMC，但是至少會在L2附上 07/14 14:36
→ elguapo: 離開交換器的時間戳記。 07/14 14:36
就像 e大您一直在強調，問道什麼場合誰誰誰是主時鐘？
但裏面有一堆人其實跟本不在一起工作
https://i.imgur.com/sf1EZ2s.jpg
您看這張圖，RTP 在 Layer 5
一般的網通設備根本不認得 Layer 5 裏的東西是什麼
就只是單純的 payload data
你看一般 Multilayer switch 最多也只到 L3 or L4
你買台能認得 Layer 5 or up 的設備
這根本會是台如視訊這類專門用途的東西
我想說的是，他們在不同「Layer」，不要一直糾結根本在不同層的時鐘
這回樣又能回到 Roon 串中所言及的
例如，在您的問題中，您正在談論以完全不同的方式影響系統的各種時鐘，並
認為也許我們對一種時鐘的討論也適用於其他時鐘。這種混亂部分是你們造成
的，部分是我們造成的，但它很好地代表了總體情況。
→ bt092001: 我覺得e大要先看一下serial link and physical layer ， 07/14 14:55
→ bt092001: 感覺e大還沒有這兩種概念 07/14 14:55
→ elguapo: IEEE1588 BC 交換器也僅是L3。RTP stream 會把 Ref CLK 07/14 14:59
→ elguapo: 資訊包含在內。每個 stream 裡面的每個 packets 都打上 07/14 14:59
→ elguapo: 時戳以便下一個節點recover clock。 07/14 14:59
→ elguapo: @bt092001 我手上有 AES3 AES5 AES11 規範的完整版，也 07/14 15:02
→ elguapo: 有買 DAC 設計相關的叢書來念。或許我真的不是讀書的料， 07/14 15:02
→ elguapo: 若您認為我讀的不夠或是概念不足，可否建議我書單？ 07/14 15:02
Media clock:
The clock used by senders to sample and receivers to play digitalmedia
streams. The media clock for audio streams reads in units of samples.
一如我上面所述，Media clock 是為了 playback 對齊（同步）用的
不要把這個 timestamp 拉到傳輸過程
因為以封包為基礎的網路傳輸過程，沒有同步這回事
→ bt092001: 我覺得不是書讀的不夠，而是有點搞混， 07/14 15:10
→ bt092001: 我先想請教如果今天，您今天一直強調主時鐘同步，再您 07/14 15:10
→ bt092001: 的觀念中這個主時鐘是如何傳遞給下一級？ 07/14 15:10
→ elguapo: 就如同我在您的post的問題，手機即是ADC也同是DAC，為何I 07/14 15:11
→ elguapo: TU-T仍要指出5G network的同步問題及必須手段？您一直是 07/14 15:11
→ elguapo: 用DAC PHY 去理解整個問題，並不認為同步傳輸是有意義的 07/14 15:11
→ elguapo: 。我個人不會去challenge個人想法，我也會同意您的見解。 07/14 15:11
→ elguapo: 但對於我的知識不足的部分，也請建議我書單，我會去讀。 07/14 15:11
此同步非彼同步，就跟此時鐘非彼時鐘一樣
Internet IP 網路沒有保證先發先至，在極端狀況下後發的封包是有可能先至的
→ bt092001: 就以這個同步的主時鐘來說好了，您認為怎麼轉傳到下一 07/14 15:13
→ bt092001: 級？ 07/14 15:13
→ bt092001: 如果以RJ45或是USB傳送，並沒有CLK 的IO接口，後級如何 07/14 15:18
→ bt092001: 知道這個CLK? 07/14 15:18
→ elguapo: 「此同步非彼同步」：都是IEEE1588 implementation 請問 07/14 15:19
→ elguapo: 有何不同？ 07/14 15:19
因為這個同步是應用同步，而非傳輸同步
AES67 很明顯是為了應用同步
→ elguapo: 「後級如何知道這個CLK」：SDP 會標註 Ref clock 給後一 07/14 15:23
→ elguapo: 級；若沒有 GMC 則會用本身的 system clock 為 Ref clock 07/14 15:23
→ elguapo: 。 07/14 15:23
→ elguapo: 「因為這個同步是應用同步，而非傳輸同步」：AoIP 是同步 07/14 15:25
→ elguapo: 傳輸的一種。 07/14 15:25
所以 e大您就是卡在這個點走不出來
→ bt092001: 好，所以後一級只是知道前一級的資訊，如果後一級用自己 07/14 15:28
→ bt092001: 的system CLK 去敲，是不是跟前一級的CLK不phase alignm 07/14 15:28
→ bt092001: ent？ 07/14 15:28
→ elguapo: 「因為以封包為基礎的網路傳輸過程，沒有同步這回事」：S 07/14 15:29
→ elguapo: yncE 就是在改正這件事。 07/14 15:29
→ elguapo: @bt092001 後一級會變 slave 07/14 15:32
→ bt092001: 所以我先當頻率一樣，後一級的CLK 波形長相是不是跟前一 07/14 15:36
→ bt092001: 級無關？ 07/14 15:36
→ elguapo: @bt092001 我想我已經表達過，您是認為DAC PHY可解決所 07/14 16:02
→ elguapo: 有問題的人，前端長再醜都能搞定。我同意，不爭執。我個 07/14 16:02
→ elguapo: 人剛好是站在對面，認為DAC就是要聽中央指揮的東西，不 07/14 16:03
→ elguapo: 聽指揮就抱歉移除，聲音再好，不合群的也只能請離。應該 07/14 16:03
→ elguapo: 沒有人說DAC PHY是永遠不能改動或改進去配合時鐘同步吧？ 07/14 16:03
S/PDIF 或 Dante-enabled
但絕大多數的用戶都是本機輸出，少部分有 local 串流 like Roon RAAT
追求傳輸過程精確同步實在沒多少意義
而且嚴格說 AES67 追求的是短延遲、媒體同步
而這並不需要超精準時鐘
→ yys310: 爆音或靜默？ 07/14 16:08
→ bt092001: E大的想法偏向parallels bus精神，但目前市售主流chip 07/14 16:15
→ bt092001: 還是異步CLK 07/14 16:15
→ elguapo: 「爆音或靜默？」：我熟悉的器材在偵測到 sample rate ch 07/14 16:22
→ elguapo: ange 或是 GMC change 是自動靜默，對齊了之後再發聲。 07/14 16:22
但 e大您上面說
AoIP 是每個 node 都在做 drift correction。司空見慣
→ elguapo: 「這並不需要超精準時鐘」：AES67主時鐘規範同AES11，必 07/14 16:28
→ elguapo: 須達 Grade 1。Grade 1「看似」不精準，但現有器材放眼 07/14 16:28
→ elguapo: 望去還真的沒幾款。 07/14 16:28
→ elguapo: Sample rate change from 48KHz to 96KHz 並不是 drift c 07/14 16:33
→ elguapo: orrection 保護的範圍；GMC change 若兩個 GMC 的 ppm 差 07/14 16:33
→ elguapo: 異不大（例如兩個 Grade 1 GPS PTP GMC）那麼頂多是顯示 07/14 16:33
→ elguapo: 重新鎖定但音頻不會靜默（這部分是 SMPTE ST2110 的 redu 07/14 16:33
→ elguapo: ndancy 會講到的）。如果是 Grade 1 降級到另一個 Grade 07/14 16:33
→ elguapo: 2 的 GMC 就可能發生重新鎖定過久而必須靜默。 07/14 16:34
→ elguapo: 順帶一提，若是採 SMPTE 規範，那麼全部器材都要達 < +-5 07/14 16:46
→ elguapo: ppm 精度，比 AES 規範還嚴苛。 07/14 16:46
‧ Grade 2 DARS (AES11 clause 5.2) ±10 ppm
‧ Grade 1 DARS optional ±1 ppm
‧ ±100 ppm adjustability, ±250 ppm recommended
1ppm 約 0.09 sec/day 約每秒 1041.667ns 的徧差
不知道有沒有算錯但好像不用壓到 10ns 的精度
所以壓到超過規範意義在哪？
僅合規範會無法正常工作、會影響音質嗎？
AES67 中我也沒看到有什麼提升音質的描述
我只能說 e大您的立論從一開始就沒有任何基礎，純粹是個人想像
→ elguapo: 「好像不用壓到 10ns 的精度」：同意，確實是不用。新收 07/14 16:52
→ elguapo: 的網卡有這個能力也很穩定，是意外收穫。 07/14 16:52
→ elguapo: 「純粹是個人想像」：所以沒有在用AES67的您是不是也用想 07/14 16:55
→ elguapo: 像的方式否定這些使用心得？ 07/14 16:55
我否定的是無根據的不科學假設
→ elguapo: 若我的假設是被您認定不科學且無根據，我ok。就此打住， 07/14 17:04
→ elguapo: 不再回覆。 07/14 17:05
推 yys310: 推O大 07/14 18:40
→ bt092001: 建議e大看一下 Ethernet or usb or hdmi physical laye 07/14 18:41
→ bt092001: r block diagram 而且最好能知道那些電路作用，還有那 07/14 18:41
→ bt092001: 些IO到底傳什麼的定義，大概就能發現不合理處 07/14 18:41
→ bt092001: 只要知道那些block電路用途跟IO傳了什麼就好 07/14 18:43
我個人認為，數位音頻在兩個點時間關鍵
採樣的 ADC，與重建的 DAC
當聲音被轉成離散的 PCM ，就沒有時鐘的問題，因為這是單純的數據
這也是 Roon 在討論串中想表達的
也所以 Vitual interfac 只有定 Sampling rate
這裏的 Sampling rate 只是規格
就像 wav、fac、mp3 檔裏也會定義檔案的 Sampling rate
這是告訴使用這個檔案的人（程式），檔案裏的數據是什麼 Sampling rate
在沒有 DA 介入的狀態，數據就只是數據
除非有意的 DSP，數據不應在傳輸的過程中發生意圖外的變化
而 Drift Correction 不太可能會是在傳輸過程中需要進行的
這就跟 Dithering、Noise shaping 一樣，理想上應該在最後一段進行
推 greg7575: 無論你用掛號印出來還是PDF寄email，內容沒差 07/14 20:08
→ greg7575: sampling rate只是讀稿機的語速而已 07/14 20:08
→ greg7575: 跟想像的不一樣，表示想像力有問題ww 07/14 20:10
PCM 是以固定間隔（時間）擷取、量化的離散數據
只還數據還是數據，這個間隔就只是常數，而非實際時間
如果數據與數據間需要精確的時間，別說單純傳輸音頻數據
Digital audio 還能被 DAW 輕鬆數位後製嗎
應該很難吧，所有做出來的音樂應該都跳痛不已
這也是為什麼我會認為一開始 e大就在假設上完全想歪了
推 yys310: 那foobar 16bit時可以選dither是不該選嗎？ 07/14 20:52
一般有截斷 bit depth 才需要
但如果有對 16-bit audio data 進行 DSP，因為 DSP chain 工作在浮點
DSP 後的數據會是浮點，如果輸出為浮點或 24-bit 做不做抖動是看選擇
但如果輸出還是只能 16-bit 一般是建議要抖動，而噪聲整形就看選擇了
推 greg7575: 我一開始就知道他想歪啊 XDDD 07/14 20:57
→ greg7575: dither的話，聽無損沒差，聽有損的可以開 07/14 20:59
→ greg7575: 有損的試過聽了沒差的話就不用開。 07/14 20:59
推 greg7575: 有損的格式會有奇奇怪怪的模型壓縮，開了"可能"會好聽 07/14 21:03
所以沒需求的話不要動數據 bit perfect 給 DAC
因為音源在母帶處理後一般都包好了抖動與噪聲整形
能不破壞原始數據最好
也所以數位音量最好不要在中間做，如果要用最好用 DAC 上的數位音量
推 greg7575: windows還會很貼心的幫你切掉peak。系統底層的切 07/14 21:08
沒辦法，因為 Windows Audio 堆棧的本質是混音器
推 uone: 想借這篇問大大們 我在VST軟體上(以SIR3為例)調整音量的動作 07/14 22:57
→ uone: 會影響檔案的bit depth嗎? 等等附圖 07/14 22:58
除了某些腦子開洞的 Plugin 會用整數做 DSP（這種的通常會自傲的聲明
一般 Plugin 都是用浮點處理數據，32-bit float 較常見、64-bit 較少見
另一個問題是你掛 VST 的 Host 是用什麼數據格式在處理 DSP
跟上面一樣 32-bit float 較常見、64-bit 較少見
但一般而言 DSP 完都會是浮點數
https://www.stillwellaudio.com/plugins/bitter/
這個 VST 可以顯示目前數據流的位深
在 SIR3 的前後各掛一個，就可以看到變化
※ 編輯: Oswyn (220.136.210.244 臺灣), 07/14/2023 23:13:38
推 uone: 感謝O大解惑~立刻掛上去foobar2000 2.0來串看看~ 07/14 23:23