- 第 1 页 -
Buckhorn之音频ASIO驱动开发技术分享
本文介绍Buckhorn声卡的asio驱动开发，工作原理，和一些实现方法，供有兴趣的同仁起抛砖引玉之用。限于篇幅只涉及主要框架，如需体验Buckhorn声卡，可上天猫淘宝搜“Buckhorn”或“跳羚声卡”；如需合作，或更多技术资料，欢迎访问公司主页buckhorn.com.cn上的“技术支持->技术文档”。
1. ASIO注册DllRegisterServer/DllUnregisterServer![]()
![]()
![]()
2. ASIO数据流![]()
![]()
3. ASIO与上下层的接口![]()
1. ASIO注册DllRegisterServer/DllUnregisterServer
Windows下的ASIO分32位和64位，即使在64位操作系统下，有些软件例如千千静听，还是只会去找32位的ASIO，所以在32位OS下面我们只需安装32位ASIO，而64位OS下面我们要把32位ASIO和64位ASIO都安装上。对应于32位和64位OS，Buckhorn声卡的ASIO的文件名分别为bhuasio32.dll和bhuasio64.dll，下面我们的讲解都是基于这两个文件。
1.1 ASIO的安装 Windows下的ASIO驱动其实就是一个dll程序，提供DllRegisterServer，DllUnregisterServer这两个标准接口，供安装和卸载的时候使用。安装和卸载，可以使用Windows自带的dll注册程序regsvr32：
regsvr32 /s “C:\Program Files (x86)\Buckhorn_Studio\bhasio32.dll”
regsvr32 /s “C:\Program Files (x86)\Buckhorn_Studio\bhasio64.dll”
这时bhuauioxx.dll的DllRegisterServer接口函数会被调用。
卸载时：
regsvr32 /s /u “C:\Program Files (x86)\Buckhorn_Studio\bhasio32.dll”
regsvr32 /s /u “C:\Program Files (x86)\Buckhorn_Studio\bhasio64.dll”
这时bhuauioxx.dll的DllUnregisterServer接口函数会被调用。
1.2 ASIO 接口展现 为了让上层软件找到我们的ASIO，我们需要在DllRegisterServer函数里添加下图中的两个注册表，这是ASIO规范里的要求，上层软件都会按照这个注册表去寻找出所有的ASIO接口的---如果系统安装了不止一个ASIO声卡的话。
注意，这个CLSID的值，需要大家自己为自己的产品去生成一个的，可以使用visual studio里的Tools->Create GUID，产生全球唯一的一个GUID。
在的DllRegisterServer函数里创建这两个注册表，而在DllUnregisterServer函数里删除这两个注册表。在32位OS下这样做足够了，但在64位OS下，这两个注册表仅仅是注册了bhuasio64.dll，我么还要注册一个32位的ASIO，位于“Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASIO”下。这时，上层软件就可以找到我们的ASIO了：
2. ASIO数据流
ASIO和上层软件之间的音频格式是PCM，上层软件从ASIO处看到的是有多少输入通道，有多少输出通道，没有立体声5.1声道等概念，由我们的ASIO了解到的下层物理声卡和虚拟声卡的通道数（立体声，5.1声道等），把上层软件的单声道输出组装成下层声卡可以认出的多声道输出格式。而在输入方向，ASIO会把来自声卡的多声道输入数据，分离成单声道的PCM数据流。下图以双声道声卡为例描述ASIO音频流：
具体的在输出方向组合成多声道，在输入方向分离成单声道，数据帧组装方式如下图：
3. ASIO与上下层的接口
ASIO与上层软件之间，是通过两个buffer交换数据的，这个buffer大小就是我们在ASIO设置界面里头看到的32/64/128/256/512 Sample，当ASIO把当前buffer的输出数据发送完成，并且输入数据也接收完成时，ASIO会去调用上层软件给我们的switchbuffer函数指针，上层软件这个回调函数就会把ASIO当前的buffer取走，把另一个新buffer递交给ASIO，这个新buffer里头已经由上层软件放入了需要输出的音频数据，并且输入的数据已经被上层软件copy走了。这就类似于下图的传动轮：
而ASIO与下层驱动之间，可以通过DeviceIoCotrol(READ, OVERLAPPED)输入数据，通过DeviceIoCotrol(WRITE, OVERLAPPED)输出数据的。当然，采用异步操作，就是通过switchbuffer获取新buffer之后，立即在输出方向组合成下层声卡可以接受的多声道PCM音频流，调用DeviceIoCotrol(WRITE, OVERLAPPED)输出；而在输入方向调用DeviceIoCotrol(READ, OVERLAPPED)以读取输入音频流。由于是异步读写，这些函数调用会立即返回，然后ASIO调用WaitForMultiObject等待这些所有输入输出都完成，就把传动轮转一步，也就是调用switchbuffer进行下一轮操作。
如此，ASIO音频流就流动起来了。搞定ASIO注册和数据流之后，ASIO其它接口部分就容易了，可以下载免费的asio sdk，并参考里头的spec，详细地描述了接口要求。
写得好。还有一事想请教LZ。就是关于ASIO4ALL驱动的，经常见到一种说法，说ASIO4ALL是什么软驱动不是硬驱动，因此音质没有硬驱动好，还有延迟也没有硬驱动低。相应的使用ASIO4ALL软驱动的话，声卡的表现也就差。
这里似乎得先明确一个说法，驱动应该无软硬之分，驱动本身就是软件层面的，应该说原生的和非原生的，对否？（ 这里还得插上一句，不知道ASIO4ALL与声卡的通讯之间是否需要中间件做桥梁？）
ASIO4ALL属于非原生，有点像公版驱动的意思，所以特定声卡的特定功能，比如说虚拟通道，多通道混音输出，任意路由，声卡自带DSP进行的信号处理等等肯定是没法支持，原生驱动针对声卡的一些性能优化（不是声音的优化，声音优化还是对声音做了改变）也肯定无法做到。但就软件通过ASIO4ALL来仅仅使用声卡的输入输出来说（假设不存在前面提到的中间件），是否不应该存在音质变差之说？即使声音和原生驱动有不同，是否也是因为声卡原生驱动有意的做了一些美化/音染，或者说信号经过了声卡内部的DSP混音器不可避免的有了音染？
ASIO4ALL口碑不佳的原因还有一个可能就是：自己没有原生驱动而建议使用ASIO4ALL驱动的声卡基本都是低端卡。另外还注意到有意思的现象，网上看到有人说过，ASIO4ALL驱动在有的声卡上能取得比原生驱动更低的无爆音延迟。
这里似乎得先明确一个说法，驱动应该无软硬之分，驱动本身就是软件层面的，应该说原生的和非原生的，对否？（ 这里还得插上一句，不知道ASIO4ALL与声卡的通讯之间是否需要中间件做桥梁？）
ASIO4ALL属于非原生，有点像公版驱动的意思，所以特定声卡的特定功能，比如说虚拟通道，多通道混音输出，任意路由，声卡自带DSP进行的信号处理等等肯定是没法支持，原生驱动针对声卡的一些性能优化（不是声音的优化，声音优化还是对声音做了改变）也肯定无法做到。但就软件通过ASIO4ALL来仅仅使用声卡的输入输出来说（假设不存在前面提到的中间件），是否不应该存在音质变差之说？即使声音和原生驱动有不同，是否也是因为声卡原生驱动有意的做了一些美化/音染，或者说信号经过了声卡内部的DSP混音器不可避免的有了音染？
ASIO4ALL口碑不佳的原因还有一个可能就是：自己没有原生驱动而建议使用ASIO4ALL驱动的声卡基本都是低端卡。另外还注意到有意思的现象，网上看到有人说过，ASIO4ALL驱动在有的声卡上能取得比原生驱动更低的无爆音延迟。
shenyou 发表于 19-4-28 11:01
谢谢科普，Buckhorn应该出一款高端旗舰版本的声卡，也好树立江湖地位
高端的产品线我们也在开发测试中，我们利用在通讯领域时钟jitter的高要求动态纠频偏的经验，降低音频时钟的Jitter，同时在时钟上我们采用了最稳定的时钟源系统达到采样频率准确的效果。在ADDA方面动态范围在125dB以上，THD方面主要是针对环回实验，我们的目标要达到播放与回录多次但是音色不能变，目前还在不断的实验中，这一点比做参数难太多了，这也是大多数高端产品目前仍然没有解决的问题。底噪目前可以降到uV级的水平。话放方面目前开发的样板还比较满意，还要进录音棚试验。希望这几款产品能早点研发完成跟朋友们见面。
@compusic您的理解很专业。无论是厂家原生的Asio还是ASIO4ALL驱动，都只是降低音频的延时，并不能改善音质，优美的音质要靠优秀的音频源，用户喜好的音效处理DSP，精准的时钟，高速精准的DAC，线性低噪的功放，精良的电路设计来保证。当然，这其中部分需要和wdm driver （硬件设备驱动程序，不是asio哦）进行交互/配置，而且驱动程序需要保证音频数据流的平滑不能波动，波动会导致频域和相位上的失真，甚至爆音。windows音频协议栈是比较长的，为了实现共享播放，音效插件等，windows音频协议栈也是实现了分层，越靠近硬件驱动层，延时越低，但功能也越单一。例如windows WASAPI的回环延时可以做到15ms以内，比waveout层150ms低太多了。厂家原生的硬件驱动程序可以直接在自身为asio开辟一个接口，而ASIO4ALL驱动只能在标准的windows API上（当然，会选择最靠近硬件驱动的那一层API）交互音频数据，所以延时要比厂家原生的asio高。至于为何有些厂家asio的延时反而不够好，那应该是设计上的问题，有发掘潜力的，理论上肯定能做到最好的 本帖最后由 FeiChang 于 19-4-29 12:53 编辑