作者john0312 (Chen John L)
看板Headphone
标题Re: [讨论] 刚刚发现一件惊人的事实
时间Tue Feb 28 01:16:14 2012
我之前说, 用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
1F：推 maninpink:大力推荐!! 从原理探讨起才有意义 02/28 01:21
2F：推 ZSZ1210:专业 但我看不懂orz 02/28 01:23
3F：→ kentarou:所以JPLAY无效是跟哪套播放程式做比较？ 02/28 01:24
4F：→ john0312:任何Bit perfect的播放器. 02/28 01:26
5F：推 mreosrick:所以用非同步的DAC就算用foobar也可以有JPLAY的音质吗？ 02/28 01:27
6F：→ john0312:设定正确的状况下来说, 是的. 不过更正确的说法应该是, 02/28 01:29
7F：→ john0312:JPlay会把同步DAC的输出往非同步DAC的方向拉. 02/28 01:29
8F：推 mreosrick:我还有一个疑问，就是用Audition这种编辑软体回放也有较 02/28 01:32
9F：推 sponge0121:推 这样说的话JPlay以他的售价 似乎吸引力降低不少? 02/28 01:33
10F：→ mreosrick:好的听感，这个原理又是什麽？跟JPLAY类似吗？ 02/28 01:33
11F：→ sponge0121:毕竟直接买个有非同步的DAC DDC还比较直接 02/28 01:33
12F：→ kentarou:所以有实际听过比较过了？ 02/28 01:33
13F：→ Layase1:大概因为w4s dac2不是真非同步的关系吧 我感觉差很多就是 02/28 01:36
14F：推 ShadowHeart:快点推文,免得人家以为我看不懂! 02/28 01:37
15F：→ john0312:@kentarous: 盲测下, 听不出差别. 02/28 01:38
16F：→ kentarou:用的非同步DAC是？ 02/28 01:39
17F：→ john0312:@kentarous: DIY的, XMOS XS1-L1处理器搭PCM1798. 02/28 01:42
18F：→ kentarou:感谢释疑。 02/28 01:45
19F：→ john0312:@mreosrick: Audition我没拆开来分析过, 所以不敢下定论. 02/28 01:50
20F：推 AKawashima:最近也在研究拨放软体，有一篇论文在探讨bit-perfect的 02/28 01:51
21F：→ AKawashima:情形下，电脑端的拨放软体为什麽会有jitter的差异进而 02/28 01:52
22F：→ AKawashima:对声音产生影响，有兴趣的可以看一下这篇论文: 02/28 01:53
24F：→ AKawashima:作者的主要论点简单来说应该是播放音乐的过程中，系统 02/28 01:55
25F：→ AKawashima:任何多余的读写或计算都有可能造成参考店为的不稳定， 02/28 01:56
26F：→ AKawashima: 电位 02/28 01:57
27F：→ AKawashima:进而产生jitter 02/28 01:58
28F：→ AKawashima:我还没有很详细去阅读他参考的文献，所以也难以判断他 02/28 02:01
29F：→ AKawashima:的理论正确与反，有兴趣的网友可以去研究看看 ^^ 02/28 02:01
30F：→ john0312:确实, 如果DAC并非独立功电, 且电源设计不扎实, 就会有 02/28 02:03
31F：→ john0312:他所说的状况. 所以我才多加了一项, 就是要独立电源. 02/28 02:04
32F：推 concord:难得看到有人分享底层的东西，一定要推的 02/28 02:08
33F：推 Dopin:讲到这样已经很里面了 要在讲程式行为与 CPU Time 与分绪就 02/28 03:03
34F：→ Dopin:太进去了 而且又会有一派扯到优化问题 (死) 02/28 03:04
35F：推 sxing6326:推!感谢释疑 02/28 03:56
36F：推 bladesinger:专业推 02/28 04:52
37F：推 hoshiyomi:"bare-bones playback engine fits completely inside 02/28 06:07
38F：→ hoshiyomi:CPU cache" <- 官网的文字游戏，大小塞的进cache不代表 02/28 06:07
39F：→ hoshiyomi:有办法独占，也没办法证明独占了就有比较好('A' 02/28 06:08
40F：推 purplesky911:好专业 02/28 06:13
41F：推 Sicimon:感谢解惑，同样用W4S DAC2却感受不到大差异的人留 02/28 06:49
42F：推 edcrfvm45:推! 有RAM BUFFER的DAC算吗? 02/28 07:00
43F：推 jackie840301:虽然看不懂，不过不推好像会漏气！！ 02/28 08:51
44F：→ concord:快推，不然人家会以为我们看不懂 XD 02/28 08:59
45F：推 chiralvosky:以这篇论点来看,除DAC独立电供,PC方面也要双电供? 02/28 09:46
46F：推 Mithrandir:to AKawashima: 那篇文章後半讨论的还是软体问题 02/28 10:05
47F：→ Mithrandir:基本上并没有触及这篇的论点， 02/28 10:05
48F：→ Mithrandir:读完後，其实就是大家都说过得东西..... 02/28 10:05
49F：→ Mithrandir:btw, 後面发现根本就是个广告文 XD 02/28 10:06
50F：→ Mithrandir:"Best results are achieved.... 02/28 10:06
51F：→ Mithrandir:......asynchronous USB DAC like AMR DP-777..." 02/28 10:07
52F：推 Mithrandir:最後一段讨论HAL, 在windows下就是走WASAPI 02/28 10:09
53F：→ Mithrandir:也就是尽量跳过系统提供的混音层, 以避免转换 02/28 10:10
54F：→ Mithrandir:vista 跟win7以前则是 ks或asio 02/28 10:10
55F：推 exquisite96:哇！原来是这样啊！(镇定) 02/28 10:11
56F：推 sostan:W4S DAC2听不太出差异+1 02/28 10:56
57F：→ hoshiyomi:其实win7下也有原生的KS支援，只是微软推WASAPI不讲而以 02/28 12:07
58F：推 bahamutuh:有非同步的dac就不太需要了 多谢~ 02/28 12:20
59F：→ xdbx:那非同步dac听了有差的话会是dac那边的问题喔? 电脑没关系齁? 02/28 12:37
60F：推 odanaga:结论就是把USB5V电从电脑分出来就不用开JPLAY(极大误 02/28 12:39
61F：推 no1smalleyes:JPLAY有试用版有没有效自己载来试试看 盲测就好啦 02/28 14:13
62F：推 chienjr:推! 02/28 14:39
63F：推 jakkx:原来如此，推一个...昨天我玩一下因为断太快太长就砍了 02/28 15:00
64F：推 sifun:专业研究! 推一个 02/28 15:32
65F：推 Hiin:看不懂先推XD 02/28 16:06
66F：推 windjammer:Weiss DAC2 foobar + Jplay 之後音场深度大增 两声道 02/28 16:34
67F：→ Sirine:可以问一下foobar的WASAPI输出算是Bit-perfect吗? 02/28 17:08
68F：推 windjammer:是阿 但是播放软体音量要100% 02/28 17:09
69F：推 windjammer:音场变大 但声音密度有点变淡 最後还是删掉 02/28 17:24
70F：→ windjammer:懒得搞那些有的没的了.... 02/28 17:24
71F：推 lowenli:某站很推的组合是搭羊羹dac 这台也是非同步的? 02/28 17:37
72F：→ lowenli:可是看这篇的话 似乎就没这麽神的感觉XD 02/28 17:38
73F：推 no1smalleyes:神不神试了就知道 这篇文就是好器材好电源基本上 02/28 19:39
74F：→ no1smalleyes:你就不需要JPLAY了 CCCC(误 02/28 19:40
75F：推 windjammer:刚刚经过盲测 Jplay对我的系统一点改变都没有 02/28 20:25
76F：→ windjammer:下午说的音场变深纯粹个人心理作用 哈哈哈哈哈 02/28 20:26
77F：推 FloatingFish:这只能推了! 02/28 21:46
78F：推 opeekon:太专业了，看了只有半懂 02/29 00:15
81F：推 mreosrick:如果照作者说是"help deliver data to DAC on time"46楼 02/29 00:28
82F：→ mreosrick:那用非同步DAC应该也可成立才是 02/29 00:29
83F：→ john0312:52楼的分析结果是, 除了统计杂讯外没有差别. 02/29 00:45
84F：→ mreosrick:然後82楼就有人提到可以用非同步DAC了 02/29 00:48
85F：→ john0312:是的, 他跟我的论点一样, 担心Jitter就用Async DAC. 02/29 00:50
86F：推 mreosrick:但我肯定跟iTunes还是有差（坚持） 02/29 00:52
87F：→ mreosrick:毕竟iTunes应该没有bit perfect吧！ 02/29 00:53
88F：→ john0312:iTune这种比较偏向一般使用者的一般比较有可能加料. 02/29 01:20
89F：→ john0312:有没有加料我也不知道, 毕竟我不用iTune. 02/29 01:21
90F：→ concord:Mac上面的iTunes是bit perfect，Windows的我不清楚(抓头 02/29 05:19