Windows上的音频采集技术比对

【转】Windows上的音频采集技术

转自http://blog.csdn.net/wxl1986622/article/details/44230149

前一段时间接到一个任务，需要采集到声卡的输出信号，以便与麦克风的输入信号进行混音。

之前一直没有研究过音频的相关技术，这次就顺便抽出一点时间去了解了一下Windows上采集音频的相关技术。

对于音频处理的技术，主要有如下几种：

• 采集麦克风输入
• 采集声卡输出
• 将音频数据送入声卡进行播放
• 对多路音频输入进行混音处理

1.Windows上音频处理的API

在Windows操作系统上，常用的音频处理技术主要包括：Wave系列API函数、DirectSound、Core Audio。

其中，Core Audio只可以在Vista以上（包括Vista）的操作系统中才能使用，主要用来取代Wave系列API函数和DirectSound。

Core Audio实现的功能也比较强大，能实现对麦克风的采集、声卡输出的采集、控制声音的播放。

而Wave系列的API函数主要是用来实现对麦克风输入的采集（使用WaveIn系列API函数）和控制声音的播放（使用后WaveOut系列函数）。

DirectSound能够实现的功能估计和Wave系列API差不多，可能会更强一些（由于没有使用过DirectSound，不太肯定!）。

为了实现采集模块对操作系统的兼容性更好，基本上对麦克风输入的采集使用WaveIn系列API函数比较多；

在Windows XP系统中，没有直接提供对声卡输出进行采集的API，因此，在Windows XP要实现对声卡输出的采集会比较麻烦。 通常可选用支持混音的声卡，然后通过使用声卡的混音模块来实现采集，但并不是所有的声卡都支持混音的功能，这样的方案不具备通用性。

要实现通用性，可以采用虚拟声卡的方式来实现，从驱动层获取声卡的输出数据，但这种方案实现难度会比较大。

而在Vista以上的系统中，如Win7，则可以使用Core Audio中的API函数来实现采集声卡输出的功能。

对于混音模块的实现，目前基本是使用自定义的混音算法来完成功能，系统没有直接的API函数可供调用。

2.使用WaveIn系列API函数实现麦克风输入采集

涉及的API函数：

• waveInOpen

  开启音频采集设备，成功后会返回设备句柄，后续的API都需要使用该句柄

  调用模块需要提供一个回调函数（waveInProc），以接收采集的音频数据

• waveInClose

  关闭音频采集模块

  成功后，由waveInOpen返回的设备句柄将不再有效 

• waveInPrepareHeader

  准备音频采集数据缓存的空间

• waveInUnprepareHeader

  清空音频采集的数据缓存

• waveInAddBuffer

  将准备好的音频数据缓存提供给音频采集设备

  在调用该API之前需要先调用waveInPrepareHeader

• waveInStart

  控制音频采集设备开始对音频数据的采集

• waveInStop

  控制音频采集设备停止对音频数据的采集

音频采集设备采集到音频数据后，会调用在waveInOpen中设置的回调函数。

其中参数包括一个消息类型，根据其消息类型就可以进行相应的操作。

如接收到WIM_DATA消息，则说明有新的音频数据被采集到，这样就可以根据需要来对这些音频数据进行处理。

（示例以后补上）

3.使用Core Audio实现对声卡输出的捕捉

涉及的接口有：

• IMMDeviceEnumerator

• IMMDevice

• IAudioClient

• IAudioCaptureClient

主要过程：

• 创建多媒体设备枚举器(IMMDeviceEnumerator)

• 通过多媒体设备枚举器获取声卡接口(IMMDevice)

• 通过声卡接口获取声卡客户端接口(IAudioClient)

• 通过声卡客户端接口(IAudioClient)可获取声卡输出的音频参数、初始化声卡、获取声卡输出缓冲区的大小、开启/停止对声卡输出的采集

• 通过声卡采集客户端接口(IAudioCaptureClient)可获取采集的声卡输出数据，并对内部缓冲区进行控制

（示例以后补上）

4.常用的混音算法

混音算法就是将多路音频输入信号根据某种规则进行运算（多路音频信号相加后做限幅处理），得到一路混合后的音频，并以此作为输出的过程。

我目前还做过这一块，搜索了一下基本有如下几种混音算法：

• 将多路音频输入信号直接相加取和作为输出

• 将多路音频输入信号直接相加取和后，再除以混音通道数，防止溢出

• 将多路音频输入信号直接相加取和后，做Clip操作（将数据限定在最大值和最小值之间），如有溢出就设最大值

• 将多路音频输入信号直接相加取和后，做饱和处理，接近最大值时进行扭曲

• 将多路音频输入信号直接相加取和后，做归一化处理，全部乘个系数，使幅值归一化

• 将多路音频输入信号直接相加取和后，使用衰减因子限制幅值

（完）

 

常见的Wndows 音频API

MME

MME是最常见的Windows音频API，全称为MutiMedia Extensions，即多媒体扩展技术。它历史悠久，兼容性好，市面上基本所有设备都能良好支持。

它属于高级的API，并不直接和硬件交流，需要通过层层接口才能访问音频硬件，这也为它带来了高延迟。虽说这种延迟在回放音频的时候并不会造成音质的劣化，但对音频的处理和录制却有着较大的负面影响。

 

DirectX Sound

　　微软的DirectX大家都一定很熟悉，玩游戏之前都需要先安装一下。实际上，DirectX也包含了音频的部分，主要为游戏提供音频接口，减少游戏中画音不同步的现象。

DirectX Sound侧重于音频输出，能直接访问硬件，响应速度得到了极大的提升。

微软在Vista系统之后对DirectX Sound进行了大改，砍掉了DirectX Sound的3D部分，

这一举动直接让EAX等依赖于DirectX Sound的3D环境音效欲哭无泪——大佬你动作之前先张声一下啊，这不是砸我饭碗么！

 

WDM

　　WDM是Windows Driver Module的缩写，拥有低延迟、支持多个音频流等特性。MME延迟高，而Direct Sound并非为专业音频设计，WDM的出现很好地弥补了这些缺点。

WDM直接和音频芯片的驱动程序交流，减少了大量中间环节，把延迟降低到一个新的层次，目前不少专业音频软件都提供了WDM接口。

 

UAA

　　UAA是最新的Windows音频架构，在Vista推出之时面世。UAA全称为Universal Audio Architecture，即通用音频架构，其中用于管理音频对话的API为WASAPI（Windows Audio Session API）。

WASAPI可以对每组音频对话单独处理，这显得意义重大。

举个例子，使用WASAPI的时候，如果正在用44.1kHz的采样率播放音乐，但此时音频采样率为48kHz的QQ又响了，就不必以混响解决，不会产生采样率转换（SRC）劣化音质的情况。事实上，WASAPI这个音频API是很多音乐发烧友的标配。

 

Kernel Streaming

　　就和其名字一样，这个API可以使音频直接访问底层数据，绕过系统的各种接口。它能带给音频极低的延迟。不过Kernel Streaming也有其局限性，

首先使用这个API会直接霸占音频硬件，你听歌的时候就没法听到QQ响；其次这个API没有音频输入功能，也没法使用麦克风。

　　ASIO

　ASIO是由德国Steinberg公司提供的音频接口，主要应用于专业领域。它的特色在于延迟极地，Windows 自有的 MME 驱动程式其延迟时间为 200~500 毫秒，

DirectSound 为 50~100 毫秒，使用ASIO却能把延迟降低至10毫秒以下，十分惊人。

低延迟对声音录制和后期制作有着重大的意义，但是在声音回放上的效果却有争议。有的发烧友认为，ASIO的低延迟可以极大程度地减少音频Jitter（抖动，这个会在后面提到），从而提高音质；

但有另一种说法称ASIO对软硬件的环境要求都比较苛刻，如果音频驱动编写水平一般，很容易产生爆音、声音生冷等问题。

　　其他常见的音频API还有EAX、OpenAL等，但是这些API一般是在游戏等应用程序中的音效中使用，很少在聆听音乐的时候用到，就略过不提了