當Foobar要唱88.2KHz的音樂時,它發現音效卡的S/PDIF輸出不能跑88.2KHz,
這時,Foobar要怎麼辦?
其一,將88.2KHz轉成44.1KHz,再傳給音效卡的device driver
其二,通知使用者,音效卡的S/PDIF輸出不能跑88.2KHz
否則88.2KHz的資料送給音效卡的S/PDIF根本就不能跑啊...那又怎麼傳到DA10去?
Foobar做的是哪項?
我輩重視音樂重播之正確性者,又偏好哪項?
若是iTunes或Media player會怎麼做呢?
才不管,直接丟給OS的audio API,這API會自己轉換格式成44.1KHz給音效卡的driver
USB與I2S都一種硬體bus,USB上當然傳的不是I2S,
USB上的資料是一批一批送,I2S上是不間斷的規律送
以USB DAC這個盒子來說,
前段是USB controller,通常是個8051 based的IC,這部份透過USB bus和PC上的device driver溝通,
由PC取得一批一批的資料存在buffer裡,若傳輸的過程有錯,可以重傳(driver與USB controller有沒有做這種機制,那是另一回事);
buffer中的資料再被規律的取出,一個一個sample經過I2S傳給DAC IC
USB 2.0的總頻寬是480Mbps,而二聲道24bits/44.1KHz的audio訊號不過是2.1168Mbps而已,
一個8051 based的flash drive搬資料的速度可以高達數百Mbps,也不會出錯,
要搞定2.1168Mbps的資料實在是...
至於USB上的資料實際上是啥內容?那就看device driver與USB controller的程式怎麼寫,
我想應該會是簡單的在一批PCM code外包上一些packet的header/tail之類的。
而I2S上的資料則是serial的PCM code,左右聲道交互傳
我贊同這作法,至少可以避開一堆PC內部的電源及電磁雜訊
若要更徹底,如Linn或是Apple Airport Express那般,透過網路傳輸,那就與PC的電源完全隔離了
(網路線必須經過變壓器,無線則相關性更低)
http://1.bp.blogspot.com/-TQtE9WuQCV...rt+Express.jpg
以你提出的這個例子而言,眼前就有iTunes -> Airport Express -> DA10能做到
這形式iTunes直接透過網路傳輸,並未經過OS的那些audio API,也不會用到sound card,該是個好方式
而且DA10又有Lavry獨門的壓低jitter技術,無需如同HD Micromega或La Rosita那般還得修改Airport Express
只是...我也不知道這傳輸的AirPlay protocol是否能跑88.2KHz...
CD quality倒是沒啥問題,前幾天我用這種形式接Moon 650D這個用上ESS Sabre也能壓低jitter的DAC,聲音確實相當的好~
http://4.bp.blogspot.com/-my5wmj4aA1.../moon+650D.jpg
前者,純軟體,只能對數位資料處理,
WAV檔,內部也是PCM code,包個頭而已
ALAC與FLAC則是壓縮過的PCM code
player軟體做的是便是讀出檔案,取出其中的PCM code(解壓縮或直接取出),
1.送給OS的audio API,再送到device driver後,透過連接該device的bus送出PCM code給device(也就是DAC卡或盒),
或是如iTunes的Airplay
2.透過OS的network API,送到Airport Express或Apple TV
DAC卡、盒、Airport Express或Apple TV收到一批批的PCM code後,再透過I2S一個一個sample送到DAC IC轉成類比
jitter就發生在這I2S(以及外加的那條Master clock訊號)+ DAC IC這裡
無論前端如何,最終要注意的就是此處