PTT數位生活區 / Headphone (耳機)

Re: [討論] USB DAC的架構

看板Headphone (耳機)作者 (調適生活)時間16年前 (2009/06/06 16:04), 編輯推噓6(6推 0噓 62→)
留言68則, 3人參與, 最新討論串4/4 (看更多)
看到K兄的推文再來分享一下好了 小弟以前碩士論文作PLL的，CDR算是PLL的一種應用 CDR的全名叫Clock/Data Recovery，這是一種通稱， 根據不同的系統，它的電路會有很多差異 USB制定的三種Clock Synchronize模式就是在針對isochronous mode， 做Clock/Data Recovery的方式 對於Synchronous Mode來說，因為是根據Frame Clock， 所以對於48 kHz取樣頻率很容易做(因為是Frame Clock的整數倍) 但是44.1 kHz就比較不容易做出來 (大約要先送出5次44 kHz再送1次45 kHz，平均起來才會是44.1 kHz) 這種機制因而漸漸沒有產品使用，只出現在早期的產品 而對於Adaptive或Asynchronous Mode來說，因為是根據接收到的資料做調整， 所以取樣頻率為多少對這兩種模式來說就較沒影響 這樣的Clock/Data Recovery只存在於USB isochronous mode上， 實際上USB本身也有存在另一種CDR，不過不是用在Audio上 是在Hub裡， 有點類似電腦網路的作法，利用Elasticity buffer (彈性緩衝器) 來達到接收端不會受到Jitter的影響導致Buffer Overflow/Underflow 而這個Elasticity Buffer的大小必須根據Jitter來決定， USB的Clock Jitter容忍範圍約為+/- 500 ppm (一般很少用"秒"，都是用ppm) 這樣代表的是誤差的容許範圍在+/- 12-Bit， 所以USB的Elasticity Buffer必需要有24-Bit的大小 方法簡述如下： 1. 先把24-Bit的Elasticity Buffer填滿一半 2. 傳送開始的同時，也會一個Bit一個Bit去填Elasticity Buffer 3. 如果接收端的Clock比傳送端快，那麼填Elasticity buffer的速度會快於資料進來， 如果接收端的Clock比傳送端慢，那麼填Elasticity buffer的速度會慢於資料進來 4. 當發生上述的第一種情形時，比較不會有太大的問題，頂多就是資料比較晚收到， 若是第二種情形，由於一開始Elasticity Buffer已經填了一半，所以資料依舊在， 只要在12個Bit Cycle裡取樣到就不會Loss 這是USB Hub的Data Recovery作法， 不過大家應該有發現到一件事，它需要時間 所以在同步傳輸裡用這個根本是找死XD -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.57.217.117
推
06/06 16:23, , 1F
這樣看起來..不管哪種clock sync,以發燒角度來看
06/06 16:23, 1F
→
06/06 16:24, , 2F
似乎都滿不理想的,變成那顆usb接收晶片很重要
06/06 16:24, 2F
→
06/06 16:46, , 3F
其實像SPDIF的clock-sync方式也有它的問題點
06/06 16:46, 3F
→
06/06 16:47, , 4F
沒有一種是像發燒友所希望的，所以不需太在意這件事
06/06 16:47, 4F
→
06/06 16:48, , 5F
太過在意到最後就很像是在聽器材而非聽音樂
06/06 16:48, 5F
推
06/06 17:25, , 6F
其實單純就usb傳輸 我比較在意的是線路雜訊亂竄的問題
06/06 17:25, 6F
→
06/06 17:29, , 7F
jitter部分在usb/1394已經沒有在spd/if時那麼決定性了
06/06 17:29, 7F
→
06/06 17:30, , 8F
稍微認真做的usb音訊裝置都不會從接收晶片那邊拉時脈吧
06/06 17:30, 8F
→
06/06 17:31, , 9F
所以usb輸出的jitter的影響是比較閒接的
06/06 17:31, 9F
→
06/06 17:32, , 10F
不過如果真的要從架構上改良 I2S+大buffer應該很徹底了
06/06 17:32, 10F
→
06/06 17:32, , 11F
Yes, 如果還從USB拉時脈，只是自己增加更多問題而已
06/06 17:32, 11F
→
06/06 17:33, , 12F
只是這樣會變成要處理buffer ram跟clock的同步問題
06/06 17:33, 12F
→
06/06 17:33, , 13F
我是覺得jitter這東西是非得處理不可的 目前的calculato
06/06 17:33, 13F
→
06/06 17:36, , 14F
是建構在2bit上....扯太遠 總之音訊要在電腦上處理就
06/06 17:36, 14F
→
06/06 17:37, , 15F
得過數位化-sampling 而為了要把這些數位化後的資訊還原
06/06 17:37, 15F
→
06/06 17:38, , 16F
又一定需要Time info 所以處理到最後還是非得面對
06/06 17:38, 16F
→
06/06 17:39, , 17F
因此針對數位系統 與其考慮如何避開jitter 不如考慮
06/06 17:39, 17F
→
06/06 17:39, , 18F
其實也不是只有像2-bit Gray Code那樣，在LVDS上有用到
06/06 17:39, 18F
→
06/06 17:39, , 19F
8b/10b encoding，不過那是屬於Video的應用
06/06 17:39, 19F
→
06/06 17:40, , 20F
把jitter問題放到哪個process會比較好處理
06/06 17:40, 20F
→
06/06 17:41, , 21F
也許是自己是做IC的，在看過或做過這些ADC或DAC後
06/06 17:41, 21F
→
06/06 17:41, , 22F
其實有一個問題很有趣 數位本質就是離散 而現實世界存在
06/06 17:41, 22F
→
06/06 17:41, , 23F
了解了ADC/DAC本身就有的缺陷，所以會認為再多的處理
06/06 17:41, 23F
→
06/06 17:42, , 24F
也沒辦法完全瀰補ADC/DAC的天生缺點
06/06 17:42, 24F
→
06/06 17:42, , 25F
的卻是連續(不考慮量子等級的微觀啦...那樣看的話 世界
06/06 17:42, 25F
→
06/06 17:43, , 26F
確實也是離散的) 但我們卻用離散方式去模擬連續 再用
06/06 17:43, 26F
→
06/06 17:43, , 27F
Yes, 所以discrete-to-continous或是反過來，都一定會有
06/06 17:43, 27F
→
06/06 17:43, , 28F
Quantization Error/Noise存在...這個是怎樣也避不掉的
06/06 17:43, 28F
→
06/06 17:44, , 29F
連續性質的元件模擬離散性質的電路來演算這些真正純離散
06/06 17:44, 29F
→
06/06 17:44, , 30F
的演算法 這樣去看就會發現有問題存在是很正常的
06/06 17:44, 30F
→
06/06 17:45, , 31F
這也沒辦法，世界上沒有真正ideal的Switch存在
06/06 17:45, 31F
推
06/06 17:46, , 32F
不過玩音響,不就是盡量追求極限嗎..XD
06/06 17:46, 32F
→
06/06 17:46, , 33F
這也造成了數位電路的極限
06/06 17:46, 33F
→
06/06 17:46, , 34F
所以4bit 8bit 16bit的演算法即使有辦法在電路上實做
06/06 17:46, 34F
→
06/06 17:46, , 35F
要真正的極限大概是弄個真空音響室...保證跟理論相同XD
06/06 17:46, 35F
→
06/06 17:46, , 36F
也就是能在開/關以外找出其他更穩定的狀態 確實可以提高
06/06 17:46, 36F
→
06/06 17:47, , 37F
演算效率 但是離散與連續本質的矛盾始終存在....除非
06/06 17:47, 37F
→
06/06 17:47, , 38F
還是要"人"來聽啦 這本來就玩給自己爽的=w=
06/06 17:47, 38F
→
06/06 17:48, , 39F
這個就會牽涉到半導體製程啦...開/關確實是半導體中
06/06 17:48, 39F
→
06/06 17:48, , 40F
量子等級精確度的數位化真的能夠實現.......真的這樣的
06/06 17:48, 40F
→
06/06 17:48, , 41F
最穩定的state，這也是二進位為何延用至今
06/06 17:48, 41F
→
06/06 17:49, , 42F
話....理論上可以用演算法重現完整的世界...理論上
06/06 17:49, 42F
→
06/06 17:50, , 43F
是啊 多bit計算系統喊很久了 生化/量子/光都有理論
06/06 17:50, 43F
→
06/06 17:50, , 44F
跟實做(實驗性的做) 但是最後穩定實用的還是on/off
06/06 17:50, 44F
→
06/06 17:50, , 45F
那些都還很遠啦 幾十年後再說的東西了
06/06 17:50, 45F
→
06/06 17:52, , 46F
幾十年不夠吧 別的不說 只要能在on/off以外多找一個狀態
06/06 17:52, 46F
→
06/06 17:52, , 47F
計算效率直接平方...
06/06 17:52, 47F
→
06/06 17:53, , 48F
真的做出來，唯一篤定的是MOS就沒有用處了XD
06/06 17:53, 48F
推
06/06 17:55, , 49F
讓他也具有多bit性質就ok了吧...我覺得數位電路的基礎理
06/06 17:55, 49F
→
06/06 17:56, , 50F
論不會變動太多...但是元件/製程會徹底革新
06/06 17:56, 50F
→
06/06 17:56, , 51F
...........徹底離題了
06/06 17:56, 51F
→
06/07 09:53, , 52F
No，MOS還有多Bit性質就不是MOS了
06/07 09:53, 52F
→
06/07 09:53, , 53F
另外，數位電路的理論絕對不是小改，而是大翻新
06/07 09:53, 53F
→
06/07 09:53, , 54F
因為數位電路全部都是基於二進位去實現的
06/07 09:53, 54F
→
06/07 09:54, , 55F
離題過遠...再講下去我看我會講MOS的電氣特性XD
06/07 09:54, 55F
推
06/07 10:44, , 56F
我講的是更基礎的理論 2bit-xbit在演算法上的轉換
06/07 10:44, 56F
→
06/07 10:45, , 57F
早就有理論了吧 那些量子/生化/光電腦都是多bit架構的
06/07 10:45, 57F
→
06/07 10:46, , 58F
實踐/挑戰者 基礎理論是沒有問題的....硬體實做就.....
06/07 10:46, 58F
→
06/07 10:48, , 59F
而且我猜初期還是會有類似MOS功能的新元件去取代MOS
06/07 10:48, 59F
→
06/07 10:48, , 60F
只是他一定得具有多bit的性質......純嘴砲XD
06/07 10:48, 60F
→
06/07 11:11, , 61F
但是研究者獨缺做EE的人...因為做電路跟理論是兩回事
06/07 11:11, 61F
→
06/07 11:13, , 62F
對我們EE的人來說，理論就類似電子電路方面的內容
06/07 11:13, 62F
→
06/07 11:14, , 63F
一旦理論無法拓展到電路層面，演算法就沒有意義...
06/07 11:14, 63F
→
06/07 11:15, , 64F
可以說是EE的人太笨，也可以說是EE的人太現實
06/07 11:15, 64F
→
06/07 11:15, , 65F
另外我說的電路理論大改指的是"電路設計"的方式
06/07 11:15, 65F
→
06/07 11:16, , 66F
而非演算法的實現...
06/07 11:16, 66F
推
06/07 17:31, , 67F
同意 現在就是這麼回事 純數位的理論可以無限衍生
06/07 17:31, 67F
→
06/07 17:31, , 68F
但是最後還是要落實到電路...或是說元件
06/07 17:31, 68F
‣ 更多 aztec1234 的文章
文章代碼(AID): #1AAYC9oF (Headphone)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 4 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共4篇)
Headphone 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 aztec1234 的文章
文章代碼(AID): #1AAYC9oF (Headphone)