Re: [討論] 剛剛發現一件驚人的事實

看板Headphone作者 (Chen John L)時間13年前 (2012/02/28 01:16), 編輯推噓39(39推 0噓 51→)
留言90則, 35人參與, 最新討論串3/3 (看更多)
我之前說, 用Async DAC的話, JPlay就無效; 然後有人問為什麼. 由於解釋這個現象需要 一定的篇幅, 所以我決定回文. 本篇會先分析JPlay軟體的內部運作, 之後再 討論他內部為什麼這樣運作(原理討論), 然後 討論這種做法為什麼在使用Async DAC的狀況 下會沒有作用, 最後給出建議以及結論. 1. JPlay內部運作分析 JPlay這個軟體我有稍微分析一下其內部運作 原理. 當然, 由於該軟體的大小(200+kB)不太 可能在一兩天內全部分析完. 因此我只分析了 重點部分, 細節部分省略. 他本身提供一個輸出介面, 也就是讓其他軟體 能輸出聲音的介面, 這個介面就是jplay.exe, 他會在系統中建立兩個Pipe, \\.\pipe\JPLAYPipeIn 以及\\.\pipe\JPLAYPipeOut. 而其他播放軟體 的Plugin (jplay_for_xxx.exe, jplaymini.exe, foo_jplay.dll) 會透過這兩個Pipe來跟 jplay.exe溝通, 傳輸音訊, 或指定要播放的檔案. 部分檔案, 如FLAC檔, JPlay會做Full Memory Buffering, 將整個檔案吃在記憶體中, 而其他 的檔案類型就沒有這樣的待遇. jplay.exe在播放音訊時, 會對系統中的各個 執行中的程序以及其執行緒做一些調整, 例如 設定他的優先權, Priority Boost等性質. 另外他也會透過呼叫SetProcessAffinityMask() 的方式來逼迫部分執行緒只在CPU的某個核心上 執行. 值得注意的是, 分析中沒有發現任何驅動程式, 也就是可執行於Ring0的.sys檔. 這說明, JPlay 完全執行於Ring3. 最後, 分析中沒有發現該軟體有任何惡意行為, 所以小紅傘判定其為惡意軟體應該是False Positive. 2. JPlay方法原理討論 JPlay本身的設計著重在改變作業系統排程部分, 他透過Windows作業系統供給的Native API來修改 各個執行序的性質, 讓處理音訊的執行緒更能準時 的獲得CPU時間. 根據官方的敘述, JPlay能減少作業系統(排程) 所造成的Jitter. 而JPlay所做的, 改變系統排程 的行為, 確實會影響音訊資料從Ring3進入Ring0的 時間. 但資料進入Ring0之後, 到從硬體端進入 DAC IC, 變成音訊資料這段, 仍然會因為驅動程式 及DAC處理Clock的方式的不同而不造成影響或 造成不同曾度的影響. 關於他所做的Full Memory Buffering, 目的是 盡量不讓硬碟在播放音訊時轉動. 這種做法確實 可以減少硬碟轉動的時間. 但若有其他程式在播放 音訊時存取硬碟, 硬碟還是會被迫轉動. 由於 微軟官方沒有提供任何控制硬碟的API, 因此, 這種做法是Windows下可以做到最好的境界了. 阻止硬碟轉動的目的是減少硬碟對電源的影響. 另外, 官方也宣稱JPlay是Bit Perfect的, 由於 分析過程中沒有看到任何DSP演算法(FIR, IIR.. etc), 而且做到Bit Perfect不困難, 因此我選擇相信 JPlay是Bit Perfect的. 也就是說, 在音訊資料 上, 他與其他Bit Perfect軟體的輸出是一樣的. 3. JPlay何時不生效 從以上的分析看來, JPlay有兩個重點: i. 更準時的將資料從Ring3交到Ring0 ii. 減少硬碟對電源造成的影響 首先討論i., 音訊資料從Ring3進入Ring0之後, 還會透過USB之類的介面傳輸到DAC, DAC內部 還會有緩衝區, 資料到了緩衝區之後才會到 DAC IC, 被轉換成類比訊號. 而Jitter的重點 在資料進入DAC IC的速度變化, 也就是說, 資料進入Ring0的速度變化如果會影響資料進入 DAC IC的速度變化, 那軟體不規律的將資料 交給Ring0將會造成Jitter, 而JPlay將會移除 這Jitter. 然而, 如果資料進入DAC的速度跟資料進入 Ring0的速度完全沒關係, 那軟體就無法造成 任何Jitter, 也就是任何Bit Perfect的軟體 通通都會有一樣的結果, 不會有差別. 既然 軟體不造成任何Jitter, 那JPlay自然也無法 移除那不存在的Jitter. 這就是為什麼JPlay 對Async DAC沒有效果. 因為Async DAC將資料 喂給DAC IC的速度是Async DAC內部的震盪器 決定的, 他根本不管電腦那端在幹麻. 再來, 關於ii., 電源的部分. 首先, 我們知道, 硬碟在讀取時, 磁盤的動能是由電源供應12V 轉換來的. 這個讓磁盤轉動的動作會瞬間吃大量 的電流, 根據我的量測有時會到2A~3A. 這種 瞬間性的負載確實會造成電源供應12V的雜訊. 但一般DAC吃的是5V. 不過大多低階電源供應 使用的架構(Forward with Multi-tap)會讓12V 影響5V, 讓這硬碟的雜訊進入5V. 但是大多 優良的DAC都有良好的Voltage Regulator, 或者是外接電源, 因此不受電腦的電源雜訊 影響. 也就是說, 如果你的DAC是吃USB的電, 而且輸入Voltage Regulator設計不良, 那 JPlay減少硬碟活動確實會有影響, 但這種情況 下, 我會建議換一顆DAC, 畢竟硬碟不是唯一 的雜訊源. 4. 建議與結論 根據上面的討論, 我認為如果使用Async DAC, 且該DAC使用獨立電源, 或電源處理合格, 則任何 Bit Perfect的播放軟體都一樣. 用JPlay不會 比較好或比較差. 另外, JPlay只做到Ring 3, 因此Sync DAC使用者, 或打算開發類似JPlay軟體的工程師可以考慮使用 Linux, 透過從Ring0微調Linux排程以及其他相關 程式碼, 可以比JPlay更上一層. 或者是直接使用 如QNX之類的RTOS. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.134.19.219
推
02/28 01:21, , 1F
大力推薦!! 從原理探討起才有意義
02/28 01:21, 1F
推
02/28 01:23, , 2F
專業 但我看不懂orz
02/28 01:23, 2F
→
02/28 01:24, , 3F
所以JPLAY無效是跟哪套播放程式做比較？
02/28 01:24, 3F
→
02/28 01:26, , 4F
任何Bit perfect的播放器.
02/28 01:26, 4F
推
02/28 01:27, , 5F
所以用非同步的DAC就算用foobar也可以有JPLAY的音質嗎？
02/28 01:27, 5F
→
02/28 01:29, , 6F
設定正確的狀況下來說, 是的. 不過更正確的說法應該是,
02/28 01:29, 6F
→
02/28 01:29, , 7F
JPlay會把同步DAC的輸出往非同步DAC的方向拉.
02/28 01:29, 7F
推
02/28 01:32, , 8F
我還有一個疑問，就是用Audition這種編輯軟體回放也有較
02/28 01:32, 8F
推
02/28 01:33, , 9F
推 這樣說的話JPlay以他的售價 似乎吸引力降低不少?
02/28 01:33, 9F
→
02/28 01:33, , 10F
好的聽感，這個原理又是什麼？跟JPLAY類似嗎？
02/28 01:33, 10F
→
02/28 01:33, , 11F
畢竟直接買個有非同步的DAC DDC還比較直接
02/28 01:33, 11F
→
02/28 01:33, , 12F
所以有實際聽過比較過了？
02/28 01:33, 12F
→
02/28 01:36, , 13F
大概因為w4s dac2不是真非同步的關係吧 我感覺差很多就是
02/28 01:36, 13F
推
02/28 01:37, , 14F
快點推文,免得人家以為我看不懂!
02/28 01:37, 14F
→
02/28 01:38, , 15F
@kentarous: 盲測下, 聽不出差別.
02/28 01:38, 15F
→
02/28 01:39, , 16F
用的非同步DAC是？
02/28 01:39, 16F
→
02/28 01:42, , 17F
@kentarous: DIY的, XMOS XS1-L1處理器搭PCM1798.
02/28 01:42, 17F
→
02/28 01:45, , 18F
感謝釋疑。
02/28 01:45, 18F
→
02/28 01:50, , 19F
@mreosrick: Audition我沒拆開來分析過, 所以不敢下定論.
02/28 01:50, 19F
推
02/28 01:51, , 20F
最近也在研究撥放軟體，有一篇論文在探討bit-perfect的
02/28 01:51, 20F
→
02/28 01:52, , 21F
情形下，電腦端的撥放軟體為什麼會有jitter的差異進而
02/28 01:52, 21F
→
02/28 01:53, , 22F
對聲音產生影響，有興趣的可以看一下這篇論文:
02/28 01:53, 22F
→
02/28 01:54, , 23F
02/28 01:54, 23F
→
02/28 01:55, , 24F
作者的主要論點簡單來說應該是播放音樂的過程中，系統
02/28 01:55, 24F
→
02/28 01:56, , 25F
任何多餘的讀寫或計算都有可能造成參考店為的不穩定，
02/28 01:56, 25F
→
02/28 01:57, , 26F
電位
02/28 01:57, 26F
→
02/28 01:58, , 27F
進而產生jitter
02/28 01:58, 27F
→
02/28 02:01, , 28F
我還沒有很詳細去閱讀他參考的文獻，所以也難以判斷他
02/28 02:01, 28F
→
02/28 02:01, , 29F
的理論正確與反，有興趣的網友可以去研究看看 ^^
02/28 02:01, 29F
→
02/28 02:03, , 30F
確實, 如果DAC並非獨立功電, 且電源設計不扎實, 就會有
02/28 02:03, 30F
→
02/28 02:04, , 31F
他所說的狀況. 所以我才多加了一項, 就是要獨立電源.
02/28 02:04, 31F
推
02/28 02:08, , 32F
難得看到有人分享底層的東西，一定要推的
02/28 02:08, 32F
推
02/28 03:03, , 33F
講到這樣已經很裡面了 要在講程式行為與 CPU Time 與分緒就
02/28 03:03, 33F
→
02/28 03:04, , 34F
太進去了 而且又會有一派扯到優化問題 (死)
02/28 03:04, 34F
推
02/28 03:56, , 35F
推!感謝釋疑
02/28 03:56, 35F
推
02/28 04:52, , 36F
專業推
02/28 04:52, 36F
推
02/28 06:07, , 37F
"bare-bones playback engine fits completely inside
02/28 06:07, 37F
→
02/28 06:07, , 38F
CPU cache" <- 官網的文字遊戲，大小塞的進cache不代表
02/28 06:07, 38F
→
02/28 06:08, , 39F
有辦法獨佔，也沒辦法證明獨佔了就有比較好('A'
02/28 06:08, 39F
推
02/28 06:13, , 40F
好專業
02/28 06:13, 40F
推
02/28 06:49, , 41F
感謝解惑，同樣用W4S DAC2卻感受不到大差異的人留
02/28 06:49, 41F
推
02/28 07:00, , 42F
推! 有RAM BUFFER的DAC算嗎?
02/28 07:00, 42F
推
02/28 08:51, , 43F
雖然看不懂，不過不推好像會漏氣！！
02/28 08:51, 43F
→
02/28 08:59, , 44F
快推，不然人家會以為我們看不懂 XD
02/28 08:59, 44F
推
02/28 09:46, , 45F
以這篇論點來看,除DAC獨立電供,PC方面也要雙電供?
02/28 09:46, 45F
推
02/28 10:05, , 46F
to AKawashima: 那篇文章後半討論的還是軟體問題
02/28 10:05, 46F
→
02/28 10:05, , 47F
基本上並沒有觸及這篇的論點，
02/28 10:05, 47F
→
02/28 10:05, , 48F
讀完後，其實就是大家都說過得東西.....
02/28 10:05, 48F
→
02/28 10:06, , 49F
btw, 後面發現根本就是個廣告文 XD
02/28 10:06, 49F
→
02/28 10:06, , 50F
"Best results are achieved....
02/28 10:06, 50F
→
02/28 10:07, , 51F
......asynchronous USB DAC like AMR DP-777..."
02/28 10:07, 51F
推
02/28 10:09, , 52F
最後一段討論HAL, 在windows下就是走WASAPI
02/28 10:09, 52F
→
02/28 10:10, , 53F
也就是盡量跳過系統提供的混音層, 以避免轉換
02/28 10:10, 53F
→
02/28 10:10, , 54F
vista 跟win7以前則是 ks或asio
02/28 10:10, 54F
推
02/28 10:11, , 55F
哇！原來是這樣啊！(鎮定)
02/28 10:11, 55F
推
02/28 10:56, , 56F
W4S DAC2聽不太出差異+1
02/28 10:56, 56F
→
02/28 12:07, , 57F
其實win7下也有原生的KS支援，只是微軟推WASAPI不講而以
02/28 12:07, 57F
推
02/28 12:20, , 58F
有非同步的dac就不太需要了 多謝~
02/28 12:20, 58F
→
02/28 12:37, , 59F
那非同步dac聽了有差的話會是dac那邊的問題喔? 電腦沒關係齁?
02/28 12:37, 59F
推
02/28 12:39, , 60F
結論就是把USB5V電從電腦分出來就不用開JPLAY(極大誤
02/28 12:39, 60F
推
02/28 14:13, , 61F
JPLAY有試用版有沒有效自己載來試試看 盲測就好啦
02/28 14:13, 61F
推
02/28 14:39, , 62F
推!
02/28 14:39, 62F
推
02/28 15:00, , 63F
原來如此，推一個...昨天我玩一下因為斷太快太長就砍了
02/28 15:00, 63F
推
02/28 15:32, , 64F
專業研究! 推一個
02/28 15:32, 64F
推
02/28 16:06, , 65F
看不懂先推XD
02/28 16:06, 65F
推
02/28 16:34, , 66F
Weiss DAC2 foobar + Jplay 之後音場深度大增 兩聲道
02/28 16:34, 66F
→
02/28 17:08, , 67F
可以問一下foobar的WASAPI輸出算是Bit-perfect嗎?
02/28 17:08, 67F
推
02/28 17:09, , 68F
是阿 但是播放軟體音量要100%
02/28 17:09, 68F
推
02/28 17:24, , 69F
音場變大 但聲音密度有點變淡 最後還是刪掉
02/28 17:24, 69F
→
02/28 17:24, , 70F
懶得搞那些有的沒的了....
02/28 17:24, 70F
推
02/28 17:37, , 71F
某站很推的組合是搭羊羹dac 這台也是非同步的?
02/28 17:37, 71F
→
02/28 17:38, , 72F
可是看這篇的話 似乎就沒這麼神的感覺XD
02/28 17:38, 72F
推
02/28 19:39, , 73F
神不神試了就知道 這篇文就是好器材好電源基本上
02/28 19:39, 73F
→
02/28 19:40, , 74F
你就不需要JPLAY了 CCCC(誤
02/28 19:40, 74F
推
02/28 20:25, , 75F
剛剛經過盲測 Jplay對我的系統一點改變都沒有
02/28 20:25, 75F
→
02/28 20:26, , 76F
下午說的音場變深純粹個人心理作用 哈哈哈哈哈
02/28 20:26, 76F
推
02/28 21:46, , 77F
這只能推了!
02/28 21:46, 77F
推
02/29 00:15, , 78F
太專業了，看了只有半懂
02/29 00:15, 78F
推
02/29 00:22, , 79F
JPLAY作者現身說法 http://ppt.cc/mPN; 35樓josef
02/29 00:22, 79F
→
02/29 00:24, , 80F
然後52樓就有人用器材分析 http://ppt.cc/owul
02/29 00:24, 80F
推
02/29 00:28, , 81F
如果照作者說是"help deliver data to DAC on time"46樓
02/29 00:28, 81F
→
02/29 00:29, , 82F
那用非同步DAC應該也可成立才是
02/29 00:29, 82F
→
02/29 00:45, , 83F
52樓的分析結果是, 除了統計雜訊外沒有差別.
02/29 00:45, 83F
→
02/29 00:48, , 84F
然後82樓就有人提到可以用非同步DAC了
02/29 00:48, 84F
→
02/29 00:50, , 85F
是的, 他跟我的論點一樣, 擔心Jitter就用Async DAC.
02/29 00:50, 85F
推
02/29 00:52, , 86F
但我肯定跟iTunes還是有差（堅持）
02/29 00:52, 86F
→
02/29 00:53, , 87F
畢竟iTunes應該沒有bit perfect吧！
02/29 00:53, 87F
→
02/29 01:20, , 88F
iTune這種比較偏向一般使用者的一般比較有可能加料.
02/29 01:20, 88F
→
02/29 01:21, , 89F
有沒有加料我也不知道, 畢竟我不用iTune.
02/29 01:21, 89F
→
02/29 05:19, , 90F
Mac上面的iTunes是bit perfect，Windows的我不清楚(抓頭
02/29 05:19, 90F
‣ 更多 john0312 的文章
文章代碼(AID): #1FIxfXVL (Headphone)
‣ 更多 john0312 的文章
文章代碼(AID): #1FIxfXVL (Headphone)