Re: [闲聊] HTPC/CAT建构的自身经验

楼主: louis0407 (能当个乡民也是一种幸福)   2020-03-14 11:47:11
最近后知后觉的注意到了这玩意:
https://reurl.cc/g7mmaQ
简单来说就是微软提供的原生UAC 2.0 Driver
(USB Audio Device Class 2.0 Driver).
最早在Win10 1703开始内建,之后慢慢改版,到了1803之后
网络有说法比XMOS Amanero之类的第三方Driver还优秀,
一时好奇下就开始测试,结果颇让我意外:
1. Wasapi(event)模式优于古早的ASIO
由于微软的UAC Driver只支援自家的DS/Wasapi模式,不支援ASIO,
所以我就先在XMOS Driver下测试Wasapi VS ASIO,结果居然发现
Wasapi(event)优于ASIO,而且差距不算小 囧,我记得十年前有ASIO
能用没人会想用Wasapi的说.
只能说,时代真的在进步,而ASIO老太旧了.就像当年的1394/firewire
也都成了历史的眼泪.
2. 微软原生UAC 2.0 Driver比XMOS原厂driver更直接一点.
同时播放程式指定32Bit模式输出在Wasapi下似乎有些好处,但在XMOS
driver下24bit好一点.这部分的差异比起Wasapi VS ASIO是比较小的.
甚至盲测应该很难过关,要质疑是心理作用我也不反对,但反正不花钱
不麻烦,有兴趣的可以加减试试.
另外补充一下foobar的相关设定:

1) wasapi的传输buffer都关掉
2) 开启MMCSS功能并指定Pro Audio模式
(最好还要去regedit编辑Pro Audio的机码内容,可参考
https://www.ptt.cc/bbs/Headphone/M.1420865982.A.F71.html
不过看MMCSS那段就好,HPET之类的我后来都拿掉或改掉了)
3) 不使用file buffering
P.S.
I Wasapi(Push)模式我没测试,看介绍一般也不太推荐
II 会测32Bit输出是因为查到的文章提到,微软提供的UAC 2.0 Driver
一开始只支援(播放程式)32Bit输出,所以猜测32Bit应该是他核心默认
的资料格式,可能可以少掉一些补0的处理,听起来也似乎差一点点点XD
III 再加上之前(前几篇文)提到的对UASP模式的支援,微软在USB Driver
这块真的很有心,不好好利用真的是很浪费.尤其UASP这块,如果音乐档案
是放在USB3.0储存装置上,差异是真的蛮大的.
作者: alanswill (小夫)   2020-03-14 12:20:00
L大好奇问个,如果说从1703后就内建的话,新电脑灌1909还有需要再安装吗?参考板上各板友目前mmcss等等的配置,fb2k走wasapi event已经赢过asio公版不少
楼主: louis0407 (能当个乡民也是一种幸福)   2020-03-14 12:29:00
抱歉让你误会了,我贴那个连结只是介绍一下,不用抓1703之后就都内建了
作者: alanswill (小夫)   2020-03-14 12:42:00
感谢L大~
作者: djboy (雞尾酒)   2020-03-14 17:44:00
推我蛮好奇,为何UASP会对声音有影响?以目前声音的传输量加上audio file不去多重确认的特性,传输快个25%有影响?
楼主: louis0407 (能当个乡民也是一种幸福)   2020-03-14 21:34:00
我只能解释到latency对讯号的SI有影响,而SI就是会直接影响听感,但我不知学理上怎么解释SI跟听感的关联uasp对我来说重点是允许双向多工的机制,这能有效降低传输延迟
作者: yamatai (回避性人格障碍症)   2020-03-14 23:56:00
latency 有影响没错,以前在抓这部分50以上到20以下差异很大,10以下每降一点点都差超多。
作者: jeeyi345 (letmein)   2020-03-15 10:27:00
可是声音不是连续的吗? 延迟到你耳朵还是完整的
作者: jan06010504 (3RD)   2020-03-15 15:30:00
昨天试了一下,自己用的DAC驱动内有特别附ASIO,结果还是比wasapi 优秀一点点,不过差距很小了,甚至可以说是味道不同而已
作者: qwerasdf856   2020-03-16 04:31:00
如果dac的asio驱动写得很好,是不会有任何错误的,延迟也比wasapi更低

Links booklink

Contact Us: admin [ a t ] ucptt.com