1我们都被骗了吗?
[中关村在线音频频道原创]PC-HiFi用户应该对ASIO都不陌生,当大家安装foobar2000这样的播放器时,总是会把ASIO插件也顺带装上。笔者当然也不例外,每次安装都是不假思索,但是没仔细想过为什么要安装这个插件,这或许跟发烧初期老烧们告诉我装了ASIO后使用这个输出声音效果会更好有关。
关于ASIO以及其他数字输出方式那些事
然而,前段时间重装foobar2000后,到其官网下载ASIO插件时,多看了一眼插件作者对该插件的说明,这一看不要紧,他讲的让我大跌眼镜,以至于对自己一直以来的习惯产生了怀疑。我们来看看他是怎么说的。
大家仔细看截图红线划出的部分,作者Peter说“与发烧友们宣称的正好相反,安装ASIO对播放音质的提升没有益处,而且ASIO的bug还可能严重降低播放的质量”。是“NO benefits”!我是看花眼了吗?相信大部分人也对此产生了疑问,这确实与发烧友们宣称的完全不一样啊!并且Peter极力推荐用户使用系统默认的输出。
到底是谁说的对呢?笔者继续在foobar2000官网寻找相关答案,在FAQ版块,笔者又找到了如下官方软件说明,见截图红线划出的部分。
与上面提到的插件说明基本一致,说“安装ASIO对播放音质的提升没有益处”,也是“NO benefits”!并且在下面提到,在大部分系统中,WASAPI输出要比ASIO稳定。
难道我们都被骗了吗?笔者对此感到十分困惑,于是又查阅了一些其他相关资料,对此渐渐有了一些新的认识。
2几种数字音频输出方式
几种数字音频输出方式
在说ASIO之前,我们先说一下几种常见的数字音频输出方式。常见的数字音频输出主要有Waveout、DirectSound、Kernel Streaming和ASIO。
Waveout是微软最早提出的音频流输出方式,所以它的兼容性也就好,几乎所有的声卡都支持。DirectSound是微软Direct X的一个组合部分,它的兼容性也很不错,并且在有多个程序需要播放音频的时候能提供高可靠的保障。
Kernel Streaming是微软底层使用的音频流方式,实际上它是以设法绕过Windows操作系统对硬件设备的控制,直接与硬件端口取得通讯的思路来实现提高响应速度的目的,能够起到输出效率高、输出延时低的效果。
ASIO是“Audio Stream Input Output”的缩写,由Steinberg提出这个标准规范,其主要目的是降低音频数据延迟,同时作为系统中独立的音频通道可以避开DirectSound或其他通道,使得ASIO下的程序可以不受系统中正在运行的其它程序的干扰,本质上是为摆脱OS对硬件的集中控制,以实现在音频处理软件与硬件之间进行多通道传输的同时将系统对音频流的响应时间降至最短。这与Kernel Streaming颇为相似。
为了对这几种输出方式有个直观的了解,我们可以看看下面这张图。
Waveout、DirectSound、Kernel Streaming和ASIO工作原理(图片来源:foobar2000中国)
从Windows Vista起,又出现了WASAPI这种输出方式。WASAPI的全称是Windows Audio Session API,这是从Windows Vista之后引入的UAA(Universal Audio Architecture)音频架构所属的API(Application Programming Interface,应用程序接口)。WASAPI允许传输未经修改的比特流到音频设备,从而避开SRC(Sample Rate Conversion,取样率转换器)的干扰。 也就是说,上图里的KMixer已经被微软淘汰了,微软想让WASAPI做的其实就是想让它像ASIO那样,运行在它下面的程序可以不受系统中正在运行的其它程序的干扰。
我们可以看到,Kernel Streaming、ASIO与WASAPI都是属于直奔底层的输出,不过ASIO与Kernel Streaming不同的是它还具有输入功能。而ASIO与WASAPI的区别在于,WASAPI的工作方式就像在多车道上专门给它划了一条车道,只供它一辆车通行;而ASIO则是干脆不走公共车道,自己专门修了另一条路,这条路上就走它自己一辆车。
3ASIO到底影响的是什么?
ASIO到底影响的是什么?
细心的朋友可能会注意到,上面说到ASIO时,介绍了其主要目的是降低音频数据延迟。这是什么意思呢?这是说ASIO对于录音作业和音乐制作的实时处理更有意义。比如你用话筒说话,就需要最好是在你发出声音的同时人们能同步听到你说话,而不是你已经讲完一句了人们才听到半句。再比如用电子琴录音,你一个键按下去了,等了0.6秒才听见了声音,那就根本没法录了。因此ASIO最大的意义就是尽可能接近“零延迟”,以保证音频的实时处理。
低延迟对于录音来说非常重要
接下来我们还要讲的一个概念就是缓存欠载。缓存欠载指的是由于某种原因导致系统传输停顿使缓存不能及时补充有效数据,同时缓存中的数据又已被播放(录制)完,造成缓存中数据为空的现象。低延迟恰恰有可能造成缓存欠载的情况。这是为什么呢?
我们知道使用ASIO时都会有一个缓冲大小设置,缓冲大小决定了当前写入位置与播放位置的距离。音乐播放速度是固定的,如果缓冲大小为0,那么就必需时刻保持写入速度等于播放速度,这势必会造成系统频繁调用的高负载。当我们加入了缓冲机制,系统对于写入速度的要求就从瞬时速度降低为平均速度的水平。缓冲越大,对于突发高负载造成的写入速度降低的缓冲能力就越强。
由此我们可以看到,对录音作业和音乐制作最有用的“零延迟”,在播放音乐时反而有可能给播放造成障碍,而一旦出现缓存欠载后,要么就会出现
看到这儿,我们对文章开头的那两个不推荐使用ASIO播放的建议总算是有了一个了解。ASIO对于音乐播放有意义的地方在于其通道的独占性而并非低延迟,这一点WASAPI同样可以做到,因此Peter更推荐用户使用WASAPI。
总结:
对于一些看似已经成为习惯而不需要讨论的东西,往往其中未必真的就不值得讨论。对于一些看似有道理的结论,如果我们能抱着一颗穷根究底的心态,或许就会发现其中的不严谨之处。即使在讨论和探究的过程中并不能推翻成论,但至少能让自己掌握更多的知识,这不也是一件好事情吗?
推荐经销商