ALSA是Advanced Linux Sound Architecture 的缩写,目前已经成为了linux的主流音频体系结构,想了解更多的关于ALSA的这一开源项目的信息和知识,请查看以下网址:http://www.alsa-project.org/。
在内核设备驱动层,ALSA提供了alsa-driver,同时在应用层,ALSA为我们提供了alsa-lib,应用程序只要调用alsa-lib提供的API,即可以完成对底层音频硬件的控制。
图 1.1 alsa的软件体系结构
由图1.1可以看出,用户空间的alsa-lib对应用程序提供统一的API接口,这样可以隐藏了驱动层的实现细节,简化了应用程序的实现难度。内核空间中,alsa-soc其实是对alsa-driver的进一步封装,它针对嵌入式设备提供了一些列增强的功能。本系列博文仅对嵌入式系统中的alsa-driver和alsa-soc进行讨论。
ALSA 标准是一个先进的 linux 声音体系。它包含内核驱动集合, API 库和工具对 Linux 声音进行支持。 ALSA 包含一系列内核驱动对不同的声卡进行支持,还提供了 libasound 的 API 库。用这些进行写程序不需要打开设备等操作,所以编程人员在写程序的时候不会被底层的东西困扰。与此相反 OSS/Free 驱动在内核层次调用,需要指定设备名和调用 ioctl 。为提供向后兼容, ALSA 提供内核模块模仿 OSS/Free 驱动,所以大多数的程序不需要改动。 ALSA 拥有调用插件的能力对新设备提供扩展,包括那些用软件模拟出来的虚拟设备。 ALSA 还提供一组命令行工具包括 mixer, sound file player 和工具控制一些特别的声卡的特别的作用。
ALSA体系主要分为三层,按照调用关系依次是,app、alsa-lib、kernel driver。
ALSA的主要特点如下:
ALSA具有更加友好的编程接口,并且完全兼容于OSS,对应用程序来讲无疑是一个更佳地选择。ALSA系统包括驱动包alsa-driver
,开发包alsa-libs
,开发包插件alsa-libplugins
,设置管理工具包alsa-utils
,其他声音相关处理小程序包alsa-tools
,特殊音频固件支持包alsa-firmware
,OSS接口兼容模拟层工具alsa-oss
共7个子项目,其中只有驱动包是必须的。
alsa-driver
指内核驱动程序,包括硬件相关的代码和一些公共代码,非常庞大。
alsa-libs
指用户空间的函数库,提供给应用程序使用,应用程序应包括头文件asoundlib.h。并使用共享库libasound.so。
alsa-utils
包含一些基于ALSA的用于控制声卡的应用程序,如alsaconf(侦测系统中声卡并写一个适合的ALSA配置文件),aplay(基于命令行的声音文件播放),arecord(基于命令行的声音文件录制)等。
Kernel driver 层,为内核驱动代码,主要在内核源码中的sound
目录下,负责对硬件进行控制与操作。驱动创建的设备文件,在文件系统中的/dev/snd/
目录下。注意,应用层使用alsa-API中打开的设备文件,并不是/dev/snd/目录下的文件,而是alsa-lib对设备的再一次封装的产物,叫做plugins
,如plughw:0,0 ,后面详细解释。
下面是我的电脑中alsa驱动的设备文件结构:
我们可以看到以下设备文件:
controlC0 --> 用于声卡的控制,例如通道选择,混音,麦克风的控制等
midiC0D0 --> 用于播放midi音频
pcmC0D0c --> 用于录音的pcm设备
pcmC0D0p --> 用于播放的pcm设备
seq --> 音序器
timer --> 定时器
其中,pcmC0D0p与pcmC0D0c组成一个pcm设备,C0代表0号声卡Card,D0代表0号设备device。C0D0代表的是声卡0中的设备0,pcmC0D0c最后一个c代表capture
,pcmC0D0p最后一个p代表playback
,这些都是alsa-driver中的命名规则。从上面的列表可以看出,我的声卡下挂了14个设备,根据声卡的实际能力,驱动实际上可以挂上更多种类的设备,在include/sound/core.h中,定义了以下设备类型:
#define SNDRV_DEV_TOPLEVEL ((__force snd_device_type_t) 0)
#define SNDRV_DEV_CONTROL ((__force snd_device_type_t) 1)
#define SNDRV_DEV_LOWLEVEL_PRE ((__force snd_device_type_t) 2)
#define SNDRV_DEV_LOWLEVEL_NORMAL ((__force snd_device_type_t) 0x1000)
#define SNDRV_DEV_PCM ((__force snd_device_type_t) 0x1001)
#define SNDRV_DEV_RAWMIDI ((__force snd_device_type_t) 0x1002)
#define SNDRV_DEV_TIMER ((__force snd_device_type_t) 0x1003)
#define SNDRV_DEV_SEQUENCER ((__force snd_device_type_t) 0x1004)
#define SNDRV_DEV_HWDEP ((__force snd_device_type_t) 0x1005)
#define SNDRV_DEV_INFO ((__force snd_device_type_t) 0x1006)
#define SNDRV_DEV_BUS ((__force snd_device_type_t) 0x1007)
#define SNDRV_DEV_CODEC ((__force snd_device_type_t) 0x1008)
#define SNDRV_DEV_JACK ((__force snd_device_type_t) 0x1009)
#define SNDRV_DEV_LOWLEVEL ((__force snd_device_type_t) 0x2000)
通常,我们更关心的是pcm和control这两种设备。
在内核中, ALSA依赖ASoC(ALSA System on Chip)驱动模型。ASoC是嵌入式系统使用的音频框架,它从硬件架构的角度来将功能相对独立的硬件单元细分出来,在驱动设备上分为 machine、 platform/CPU和CODEC
三个模块。
可以这么理解:一套嵌入式 硬件平台(Machine)包含了平台AP(Platform)和音频CODEC芯片(Codec)
,对应ASoC的三个设备驱动。这三个设备分别注册各自功能的dev设备,但都是以内核platform设备模型来创建。 ASoC主要代码位于kernel/sound/soc下。 下面分别来介绍一下:
Machine设备可以看成是一块嵌入式主板(Board) 或者一块声卡。machine设备驱动是ASoC驱动框架的入口, 主要功能是负责platform/cpu和codec之间的连接和控制,或者响应独立于Platform功能和Codec功能之外的特殊音频事件,如平台GPIO控制外置功放等,这些属于machine本身的特定操作代码,都会放到machine驱动里。
Machine设备驱动的主要功能是定义各种DAI(Digital Audio Interface) links,它的作用是把platform/cpu和codec设备驱动连接起来,形成完整的音频通路。
在内核设备树中,平台会定义一个声卡设备,它就是ASoC框架里的machine设备。 machine设备的初始化是整个ASoC驱动的入口。 machine设备的probe()
会调用snd_soc_register_card()
去注册声卡,然后在snd_soc_instantiate_card()
里实例化声卡设备的时候,调用Platform和Codec设备各自的probe()
,完成这两个设备的初始化。如果没有错误,那么声卡会注册成功,我们在/dev/snd下可以看到多个音频设备。
Platform设备可看作是平台AP(SoC主控,或CPU)。 它负责提供嵌入式平台端的音频功能, 如播放、录音、 Voice通话等。平台驱动中包括音频DMA引擎驱动,数字接口驱动(I2S, AC97, PCM)以及该平台相关的任何音频DSP驱动。此Platform可以重用,在不同的Machine中可以直接重复使用。
Platform设备驱动主要有两个作用:
(1)transfer:负责平台AP端的audio/voice数据流(stream)和DSP之间的传输;
(2)routing:将stream数据流按照特定的路线对应到其他音频模块中。
ASoC会注册多个Platform设备来负责不同功能的音频模块:
(1)负责audio回放/录音
(2)负责voice通话
(3)负责VoIP通话
(4)负责压缩格式的audio播放
(5)负责stream数据流的路线指定
对于一块嵌入式设备的主板来说,一般会集成一颗音频CODEC芯片。 ASoC架构下的CODEC设备功能和物理CODEC对应, 其在machine的控制下和platform设备连接,负责音频的实际处理,如声音播放(D/A)、声音采集(A/D) 和各种音频control控件的设置。
平台一般会集成一个CODEC单元,也会有添加外部独立CODEC芯片,已达到更好的音质。如Wolfson的WM8998芯片,它是一颗独立的CODEC,基于I2S接口从平台获取音频数据,在其内部经过DAC输出到耳机或speaker。高通有自己的外置CODEC芯片,如WCD9326/9335等,和平台AP的音频数据接口叫Slimbus,其实是和I2S复用的GPIO口。
CODEC芯片可能需要I2C或SPI控制。
COCEC设备支持耳机插拔及按键检测功能。
CODEC设备驱动中定义了大量的mixer、 mux和各种开关的kcontrol,以及DAPM使用的widget和route。
Alsa-lib层,为不同的驱动提供统一的接口alsa API,简化了开发人员对于驱动层的调用开发。主要有如下接口:
网址:https://www.alsa-project.org/alsa-doc/alsa-lib/
The currently designed interfaces are listed below:
我们在应用中,主要使用的是 PCM 接口。如Snd_pcm_open()函数。
除了Alsa-API接口以外,alsa-lib还可以通过配置文件,开放其附加功能,如采样率转换、软件混音等。
我们就是利用alsa-lib的附加功能实现我们的重采样功能,修改的地方主要包括alsa-lib的配置和APP调用两方面。下一小节对如何利用alsa-lib的配置文件开放其采样率转换功能进行描述。
asound.conf配置文件,是alsa-lib的默认配置文件,路径在 /etc/,可以用来配置alsa库的一些附加功能。这个文件不是alsa库运行时所必须的,没有它alsa库也可以正常运行。
关于asound.conf的配置,可以参考以下文档:
http://www.alsa-project.org/main/index.php/Asoundrc
先阐述一些重要的名词:
需要使用这些附加的plugin,就要对配置文件(asound.conf)进行配置,这个配置是实时生效的,所以我们不必修改文件系统中的文件,而是在运行我们的应用程序之前,将自己的配置文件拷贝到/etc/下,对默认的配置文件进行覆盖就行了。
具体如何配置,书写格式,请参看Asoundrc文档。
以下就是我的配置,
pcm_slave.sl2 {
pcm "plughw:0,1"
rate 48000
}
pcm.rate_convert {
type rate
slave sl2
}
这个配置的含义是,
下面一段:创建一个使用pcm API接口的设备,叫做rate_convert,它的类型是rate(可以实现采样率转换的plugin),它有一个slave叫做sl2;
上面一段:定义一个使用pcm接口的slave,叫做sl2,他实际上是plughw:0,1这个设备的别名,即等同于plughw:0,1(对应我用于播放的AIC3104芯片),这个设备需要的采样率是48KHz。
通过这个配置,就可以在app中,使用pcm API打开rate_convert这个设备,并把解码后的8K采样率的PCM数据,直接使用snd_pcm_writei写入设备,rate_convert这个设备就可以自动将PCM数据重采样至48KHz,然后自动传递给plughw:0,1进行播放。
在看Asoundrc的文档中,一直不明白,为什么在配置文件中,只有输出的采样率配置,而没有输入的采样率配置,要重采样,alsa-lib总得知道把啥转换成48K吧,
在实践中发现,可以通过APP调用alsa-API中的snd_pcm_hw_params_set_rate_near()函数将数据源的采样率为8K传递给alsa-lib。下面一章对app调用alsa-API进行说明。
注意:设备命名
API库使用逻辑设备名而不是设备文件。设备名字可以是真实的硬件名字也可以是插件名字。硬件名字使用hw:i,j这样的格式。其中i是卡号,j是这块声卡上的设备号。
第一个声音设备是hw:0,0.这个别名默认引用第一块声音设备并且在本文示例中一真会被用到。
插件使用另外的唯一名字,比如 plughw:,表示一个插件,这个插件不提供对硬件设备的访问,而是提供像采样率转换这样的软件特性,硬件本身并不支持这样的特性。
在app调用这块儿,其他的通用调用流程在这里就不累述了,使用个项目原来的那套代码就行,只有三块儿需要修改和注意:
1、使用snd_pcm_open()打开的设备文件rate_convert(不需再打开plughw:0,1了),PCM数据的原始采样率,用snd_pcm_hw_params_set_rate_near()对rate_convert进行配置。
2、重要的参数Period_size,即播放周期大小,单位为Byte,需使用snd_pcm_hw_params_set_period_size_near()进行配置,如果period_size配的不对,或者不配置,会发生underRun,播放声音断断续续。
8K pcm, 配置sample_rate为8000,配置period_size为256
48K pcm, 配置sample_rate为48000,配置period_size为1024
3、配置负责playback的AIC3104的采样率为48K
一块声卡有一个声卡内存用来存储记录的样本。当它被写满时就产生中断。内核驱动就使用 DMA 将数据传输到内存中。同样地,当在播放时就将内存中的声音样本使用 DMA 传到声卡的内存中!
声卡的缓存是环状的,这里只讨论应用程序中的内存结构: ALSA 将数据分成连续的片段然后传到按单元片段传输。
典型的声音程序结构:
open interface for capture or playback
set hardware parameters
(access mode, data format, channels, rate, etc.)
while there is data to be processed:
read PCM data (capture)
or write PCM data (playback)
close interface
(1)在 ALSA 的文档页面上有两篇为应用程序开发者提供的文章:
ALSA 0.9.0 HOWTO [ http://www.suse.de/~mana/alsa090_howto.html ]
(2)当然,还有音频库API的在线参考: http://www.alsa-project.org/alsa-doc/alsa-lib
(3)音频库API中各个函数的使用说明:http://www.alsa-project.org/alsa-doc/alsa-lib/modules.html
(4)http://www.sabi.co.uk/Notes/linuxSoundALSA.html
(5)a LINUX Journal article about basic ALSA programming 包含一些示例代码
(6)tutorials on the ALSA project web site 包含一些示例代码