關於數位音樂再生

[drunkenlife]

解決問題，必須找出其根源
在這數位音樂再生的過程中，
除了如kmixer之類的問題外，是否有證據顯示資料錯誤？
或者更明確的說，資料在傳遞過程中發生錯誤？
我的光纖loopback實驗則是證明資料正確，而這也符合我們對數位資料傳遞的理解，
在各式各樣電路/應用上都能正確傳遞的數位資料，自然沒啥道理在音樂再生這領域就會錯。

哪麼，再來剩下的可能是？
眼前，似乎只有jitter？
而我們知道jitter與電源純淨度大有關係，
既有此可能，那麼，對任何的動作/改變會造成聲音的差異，我們便會嘗試著去探究，是否會造成電源差異？
若果，那好，知道怎麼處理了，
若非，那，只好再繼續觀察尋找差異，並探究是否為問題的根源...

當然這種找答案的方式，有時會落入如那個著名的"我的車喜歡巧克力冰淇淋，不喜歡香草冰淇淋"例子...

各位是否有些觀察/證據可以分享？

此外，我想有些詞語大家釐清比較好，以免雞同鴨講
我們以再生的程序倒過來看，針對資料/訊號而言，
最後是類比訊號，以目前的主要架構是個電壓變化訊號；
往前推是DAC電路，通常是個IC，
往前，輸入給DAC的是數位訊號，以CD而言，這是個PCM code，也就是以數字表示電壓，我們稱這一個個PCM code為sample；
再往前是DAC卡/盒/模組的控制電路，裡面有一個buffer，存著一堆PCM code；
再往前，以PC為例，則是PCI Express或USB或Ethernet或WiFi或BlueTooth，
上面傳遞的資料通常是一批批的PCM code，或許會包個頭尾，我們稱這一批批有包頭尾的資料為packet；
再往前是PCI Express或USB或Ethernet或WiFi或BlueTooth的硬體buffer，裡面也是packet；
再往前是device driver，裡面也有個buffer，存著一批批的PCM code，通常沒有外加的頭尾；
再往前是OS針對PCI Express或USB或Ethernet或WiFi或BlueTooth的API，裡面當然還是有buffer，還是存著PCM code；
再往前是player軟體的輸出部分，裡面當然還是有buffer，還是存著PCM code；
再往前，若是唱壓縮檔，是player的解壓縮部分，其輸出部分裡面當然還是有buffer，還是存著PCM code，
其輸入部分裡面當然還是有buffer，不過存的是壓縮過的資料；
再往前是OS的storage driver，CD或硬碟或Flash drive，裡面當然還是有buffer，存著檔案的某個片段；
再往前是storage上的檔案，無論是CD或硬碟或Flash drive。

通常我們這麼說，
檔案，是在某個儲存體上已知其大小的一批資料；
stream，是透過某種傳輸媒介持續的、有先後順序的一串資料；
packet，是stream的其中一片段，有些stream並非穩定頻率不間斷的傳輸，而是送一批，停一下，又送一批。

又，除了數位的jitter外，別忘了DAC有一半是類比，
類比仍舊是需要砸重本重料才能做的好，尤其是訊號最微弱的訊源端。