当前位置: 代码迷 >> 综合 >> Linux Audio ALSA Technical specification(Linux 音频ALSA技术说明)
  详细解决方案

Linux Audio ALSA Technical specification(Linux 音频ALSA技术说明)

热度:47   发布时间:2024-01-09 03:45:02.0

 

Linux Audio ALSA Technical specification

 

备注:整理于2011.01.20, 本篇博客百度文库: http://wenku.baidu.com/view/34ca5351ad02de80d4d84084.html

Emailsafransx@gmail.com            QQ: 1104472716  

 

 

TABLE OF CONTENTS

1       ALSA Overview... 3

1.1   ALSA features. 3

1.2   ALSA子项目.... 3

1.3   ALSA接口.... 4

1.4   ALSA体系结构.... 4

1.5   ALSA-driver文件结构.... 5

1.6   Androidalsa相关代码路径.... 7

2       音频基础.... 7

2.1   数字音频基础.... 7

2.2   ALSA基础.... 8

2.3   设备命名.... 8

2.4   声音缓存和数据传输.... 8

2.5   访问音频设备.... 9

2.6   音频设备文件.... 11

3       ALSA Example.. 13

3.1   Example1. Display Some PCM Types and Formats. 13

3.2   Example2. Opening PCM Device and Setting Parameters. 16

3.3   Example3.Simple Sound Playback.. 19

3.4   Example4. Simple Sound Recording.. 21

3.5   高级特性.... 23

4       ALSA移植.... 23

5       Preference.. 24

1       ALSA Overview

      ALSA(Advanced Linux Sound Architecture(高级Linux声音体系)的缩写)是为声卡提供驱动的Linux内核组件,以替代原先的OSS(开放声音系统)。ALSA除了像OSS那样提供一组内核驱动程序模块以外,还专门为简化应用程序的编写提供了相应的库函数,与OSS提供的基于ioctl的原始编程接口相比,ALSA函数库使用起来要更加方便一点。

1.1   ALSA features

      ALSA has the following significant features:

1.Efficient support for all types of audio interfaces, from consumer sound cards to professional multichannel audio interfaces. (支持多种声卡设备)

2.Fully modularized sound drivers. (模块化的内核驱动程序)

3.SMP and thread-safe design. (支持SMP和多线程)

4.User space library (alsa-lib) to simplify application programming and provide higher level functionality. (提供应用开发函数库以简化应用程序开发)

5.Support for the older Open Sound System (OSS) API, providing binary compatibility for most OSS programs. (支持OSS API,兼容OSS应用程序)

1.2   ALSA子项目

      ALSA具有更加友好的编程接口,并且完全兼容于OSS,对应用程序来讲无疑是一个更佳地选择。ALSA系统包括以下7个子项目,其中只有驱动包是必须的:

      驱动包alsa-driver                                                

      开发包alsa-libs

      开发包插件alsa-libplugins                                  

      设置管理工具包alsa-utils

      其他声音相关处理小程序包alsa-tools              

      特殊音频固件支持包alsa-firmware

      OSS接口兼容模拟层工具alsa-oss.

      alsa-driver指内核驱动程序,包括硬件相关的代码和一些公共代码,非常庞大。

      alsa-libs指用户空间的函数库,提供给应用程序使用,应用程序应包括头文件asoundlib.h并使用共享库libasound.so

      alsa-utils包含一些基于ALSA的用于控制声卡的应用程序,如alsaconf(侦测系统中声卡并写一个适合的ALSA配置文件),aplay(基于命令行的声音文件播放),arecord(基于命令行的声音文件录制)等。

1.3   ALSA接口

      目前ALSA内核提供给用户空间的接口有:

      信息接口(proc/asound

      控制接口(dev/snd/controlCX提供管理声卡注册和请求可用设备的通用功能

      混音器接口(dev/snd/mixerCXDX

      PCM接口(dev/snd/pcmCXDX管理数字音频回放(playback)和录音(capture)的接口

      Raw迷笛接口(dev/snd/midiCXDX支持MIDI(Musical Instrument Digital Interface),标准的电子乐器。这些API提供对声卡上MIDI总线的访问。这个原始接口基于MIDI事件工作,由程序员负责管理协议以及时间处理。

      音序器接口(dev/snd/seq

      定时器接口(dev/snd/timer):为同步音频事件提供对声卡上时间处理硬件的访问。

      和OSS类似,上述接口也以文件的方式被提供,不同的是这些接口被提供给alsa-lib使用,而不是直接给应用程序使用的。应用程序最好使用alsa-lib或者更高级的接口。

1.4   ALSA体系结构

      下图所示为ALSA声卡驱动与用户空间体系结构的简图,从中可以看出ALSA内核驱动与用户空间库及OSS之间的关系

 

 

 

ALSA体系结构

 

 

 

 

1.5   ALSA-driver文件结构

 

 

      从code文件夹中找到alsa-driver-1.0.23.tar.bz2,在linux下解压,我们可以得到alsa-driver-1.0.23文件夹,我们可以看到ALSA驱动文件的目录结构:

sound

/core

    /oss

    /seq

         /oss

/include

/drivers

    /mpu401

    /op13

    /opl4

    /pcsp

/vx

/i2c

    /other

/synth

    /emux

/pci

   /(cards)
       /isa

   /(cards)

/arm

/ppc

/sparc

/usb

/pcmcia/(cards)

/oss

      下面我们来看一下各个目录的具体作用:

core目录

      这个目录包含了中间层,ALSA的核心驱动。

core/oss

      关于PCMmixerOSS模拟的模块保存在这个目录里面。Raw midi OSS模拟也被包含在ALSA rawmidi代码中,因为它非常小。音序器代码被保存在core/seq/oss目录里面

*core/ioctl32(老版本里面的)

      这个目录包含32bit-ioctl64bit架构(如x86-64,ppc64,sparc64)的转换。对于32bitalpha的架构,他们是不被编译的。

core/seq

      它和它的子目录主要是关于ALSA的音序器。它包含了音序器的core和一些主要的音序器模块如:snd-seq-midisnd-seq-virmidi等等。它们仅仅在内核配置中当CONFIG_SND_SEQUENCER被设定的时候才会被编译。我们在使用的ALSA驱动中也没有使用。

core/seq/oss

      包含了OSS音序器的模拟的代码。

core/seq/instr

      包含了一些音序器工具层的一些模块。

include目录

      这里面放的是ALSA驱动程序开放给用户空间,或者被其他不同目录引用的共同头文件。

Drivers目录

这个目录包含了不同架构的系统中的不同驱动共享的文件部分。它们是硬件无关的。在子目录里面,会放一些不同组件的代码,他们是根据不同的buscpu架构实现的。

i2c目录

      这里面包含了ALSAi2c组件。虽然LINUXi2c的标准协议层,ALSA还是拥有它关于一些card的专用i2c代码,因为一些声卡仅仅需要一些简单的操作,而标准的i2cAPI函数对此显得太过复杂了。

synth目录

      它包含了synth(合成器)的中间层模块

pci目录

      它和它的一些子目录文件负责PCI声卡和一些PCI BUS的上层card模块。

isa目录

      它和它的一些子目录文件是处理ISA声卡的上层card模块。

arm,ppcsparc目录

      这里放置一些和芯片架构相关的一些上层的card模块。

usb目录

      这里包含一些USB-AUDIO驱动。在最新版本里面,已经把USB MIDI 驱动也集成进USB-AUDIO驱动了。

pcmcia目录

      PCMCIA卡,特别是PCCcard驱动会放到这里。CardBus驱动将会放到pci目录里面,因为API函数和标准PCI卡上统一的。

oss目录

      和ALSA无关。

 

 

1.6   Androidalsa相关代码路径

 

 

 

alsa HALU6715_Android/android/src/hardware/alsa_sound

alsa-utilsU6715_Android/android/src/external/alsa-utils

alsa-lib   U6715_Android/android/src/external/alsa-lib

alsa-driverSDK/src/linux/kernel/linux/sound

 

2       音频基础

2.1   数字音频基础

      音频信号是一种连续变化的模拟信号,但计算机只能处理和记录二进制的数字信号,由自然音源得到的音频信号必须经过一定的变换,成为数字音频信号之后,才能送到计算机中作进一步的处理。

      数字音频系统通过将声波的波型转换成一系列二进制数据,来实现对原始声音的重现,实现这一步骤的设备常被称为模/数转换器(A/D)。A/D转换器以每秒钟上万次的速率对声波进行采样,每个采样点都记录下了原始模拟声波在某一时刻的状态,通常称之为样本(sample),而每一秒钟所采样的数目则称为采样频率,通过将一串连续的样本连接起来,就可以在计算机中描述一段声音了。对于采样过程中的每一个样本来说,数字音频系统会分配一定存储位来记录声波的振幅,一般称之为采样分辩率或者采样精度,采样精度越高,声音还原时就会越细腻。

      数字音频涉及到的概念非常多,对于在Linux下进行音频编程的程序员来说,最重要的是理解声音数字化的两个关键步骤:采样和量化。采样就是每隔一定时间就读一次声音信号的幅度,而量化则是将采样得到的声音信号幅度转换为数字值,从本质上讲,采样是时间上的数字化,而量化则是幅度上的数字化。下面介绍几个在进行音频编程时经常需要用到的技术指标:

1.采样频率

      采样频率是指将模拟声音波形进行数字化时,每秒钟抽取声波幅度样本的次数。采样频率的选择应该遵循奈奎斯特(Harry Nyquist)采样理论:如果对某一模拟信号进行采样,则采样后可还原的最高信号频率只有采样频率的一半,或者说只要采样频率高于输入信号最高频率的两倍,就能从采样信号系列重构原始信号。正常人听觉的频率范围大约在20Hz~20kHz之间,根据奈奎斯特采样理论,为了保证声音不失真,采样频率应该在40kHz左右。常用的音频采样频率有8kHz11.025kHz22.05kHz16kHz37.8kHz44.1kHz48kHz等,如果采用更高的采样频率,还可以达到DVD的音质。

2.量化位数

      量化位数是对模拟音频信号的幅度进行数字化,它决定了模拟信号数字化以后的动态范围,常用的有8位、12位和16位。量化位越高,信号的动态范围越大,数字化后的音频信号就越可能接近原始信号,但所需要的存贮空间也越大。

3.声道数

      声道数是反映音频数字化质量的另一个重要因素,它有单声道和双声道之分。双声道又称为立体声,在硬件中有两条线路,音质和音色都要优于单声道,但数字化后占据的存储空间的大小要比单声道多一倍。

 

2.2   ALSA基础

      ALSA由许多声卡的声卡驱动程序组成,同时它也提供一个称为libasoundAPI库。应用程序开发者应该使用libasound而不是内核中的ALSA接口。因为libasound提供最高级并且编程方便的编程接口。并且提供一个设备逻辑命名功能,这样开发者甚至不需要知道类似设备文件这样的低层接口。相反,OSS/Free驱动是在内核系统调用级上编程,它要求开发者提供设备文件名并且利用ioctrl来实现相应的功能。为了向后兼容,ALSA提供内核模块来模拟OSS,这样之前的许多在OSS基础上开发的应用程序不需要任何改动就可以在ALSA上运行。另外,libaoss库也可以模拟OSS,而它不需要内核模块。

      ALSA包含插件功能,使用插件可以扩展新的声卡驱动,包括完全用软件实现的虚拟声卡。ALSA提供一系列基于命令行的工具集,比如混音器(mixer),音频文件播放器(aplay),以及控制特定声卡特定属性的工具。

2.3   设备命名

      API库使用逻辑设备名而不是设备文件。设备名字可以是真实的硬件名字也可以是插件名字。硬件名字使用hw:i,j这样的格式。其中i是卡号,j是这块声卡上的设备号。第一个声音设备是hw:0,0.这个别名默认引用第一块声音设备并且在本文示例中一直会被用到。插件使用另外的唯一名字。比如plughw:,表示一个插件,这个插件不提供对硬件设备的访问,而是提供像采样率转换这样的软件特性,硬件本身并不支持这样的特性。

2.4   声音缓存和数据传输

      每个声卡都有一个硬件缓存区来保存记录下来的样本。当缓存区足够满时,声卡将产生一个中断。内核声卡驱动然后使用直接内存(DMA)访问通道将样本传送到内存中的应用程序缓存区。类似地,对于回放,任何应用程序使用DMA将自己的缓存区数据传送到声卡的硬件缓存区中。

      这样硬件缓存区是环缓存。也就是说当数据到达缓存区末尾时将重新回到缓存区的起始位置。ALSA维护一个指针来指向硬件缓存以及应用程序缓存区中数据操作的当前位置。从内核外部看,我们只对应用程序的缓存区感兴趣,所以本文只讨论应用程序缓存区。

      应用程序缓存区的大小可以通过ALSA库函数调用来控制。缓存区可以很大,一次传输操作可能会导致不可接受的延迟,我们把它称为延时(latency)。为了解决这个问题,ALSA将缓存区拆分成一系列周期(period)(OSS/Free中叫片断fragments).ALSAperiod为单元来传送数据。

      一个周期(period)存储一些帧(frames)。每一帧包含时间上一个点所抓取的样本。对于立体声设备,一个帧会包含两个信道上的样本。图1展示了分解过程:一个缓存区分解成周期,然后是帧,然后是样本。图中包含一些假定的数值。图中左右信道信息被交替地存储在一个帧内。这称为交错(interleaved)模式。在非交错模式中,一个信道的所有样本数据存储在另外一个信道的数据之后。

 

 

Over and Under Run

      当一个声卡活动时,数据总是连续地在硬件缓存区和应用程序缓存区间传输。但是也有例外。在录音例子中,如果应用程序读取数据不够快,循环缓存区将会被新的数据覆盖。这种数据的丢失被称为overrun.在回放例子中,如果应用程序写入数据到缓存区中的速度不够快,缓存区将会"饿死"。这样的错误被称为"underrun"。在ALSA文档中,有时将这两种情形统称为"XRUN"。适当地设计应用程序可以最小化XRUN并且可以从中恢复过来。

2.5   访问音频设备

      无论是OSS还是ALSA,都是以内核驱动程序的形式运行在Linux内核空间中的,应用程序要想访问声卡这一硬件设备,必须借助于Linux内核所提供的系统调用(system call)。从程序员的角度来说,对声卡的操作在很大程度上等同于对磁盘文件的操作:首先使用open系统调用建立起与硬件间的联系,此时返回的文件描述符将作为随后操作的标识;接着使用read系统调用从设备接收数据,或者使用write系统调用向设备写入数据,而其它所有不符合读/写这一基本模式的操作都可以由ioctl系统调用来完成;最后,使用close系统调用告诉Linux内核不会再对该设备做进一步的处理。

open系统调用

      系统调用open可以获得对声卡的访问权,同时还能为随后的系统调用做好准备,其函数原型如下所示:

 

      int open(const char *pathname, int flags, int mode);

      参数pathname是将要被打开的设备文件的名称,对于声卡来讲一般是/dev/dsp。参数flags用来指明应该以什么方式打开设备文件,它可以是O_RDONLYO_WRONLY或者O_RDWR,分别表示以只读、只写或者读写的方式打开设备文件;参数mode通常是可选的,它只有在指定的设备文件不存在时才会用到,指明新创建的文件应该具有怎样的权限。

      如果open系统调用能够成功完成,它将返回一个正整数作为文件标识符,在随后的系统调用中需要用到该标识符。如果open系统调用失败,它将返回-1,同时还会设置全局变量errno,指明是什么原因导致了错误的发生。

read系统调用

      系统调用read用来从声卡读取数据,其函数原型如下所示:

 

      int read(int fd, char *buf, size_t count);

      参数fd是设备文件的标识符,它是通过之前的open系统调用获得的;参数buf是指向缓冲区的字符指针,它用来保存从声卡获得的数据;参数count则用来限定从声卡获得的最大字节数。如果read系统调用成功完成,它将返回从声卡实际读取的字节数,通常情况会比count的值要小一些;如果read系统调用失败,它将返回-1,同时还会设置全局变量errno,来指明是什么原因导致了错误的发生。

write系统调用

      系统调用write用来向声卡写入数据,其函数原型如下所示:

 

      size_t write(int fd, const char *buf, size_t count);

      系统调用write和系统调用read在很大程度是类似的,差别只在于write是向声卡写入数据,而read则是从声卡读入数据。参数fd同样是设备文件的标识符,它也是通过之前的open系统调用获得的;参数buf是指向缓冲区的字符指针,它保存着即将向声卡写入的数据;参数count则用来限定向声卡写入的最大字节数。

      如果write系统调用成功完成,它将返回向声卡实际写入的字节数;如果write系统调用失败,它将返回-1,同时还会设置全局变量errno,来指明是什么原因导致了错误的发生。无论是read还是write,一旦调用之后Linux内核就会阻塞当前应用程序,直到数据成功地从声卡读出或者写入为止。

ioctl系统调用

      系统调用ioctl可以对声卡进行控制,凡是对设备文件的操作不符合读/写基本模式的,都是通过ioctl来完成的,它可以影响设备的行为,或者返回设备的状态,其函数原型如下所示:

 

      int ioctl(int fd, int request, ...);

      参数fd是设备文件的标识符,它是在设备打开时获得的;如果设备比较复杂,那么对它的控制请求相应地也会有很多种,参数request的目的就是用来区分不同的控制请求;通常说来,在对设备进行控制时还需要有其它参数,这要根据不同的控制请求才能确定,并且可能是与硬件设备直接相关的。

close系统调用

      当应用程序使用完声卡之后,需要用close系统调用将其关闭,以便及时释放占用的硬件资源,其函数原型如下所示:

 

      int close(int fd);

      参数fd是设备文件的标识符,它是在设备打开时获得的。一旦应用程序调用了close系统调用,Linux内核就会释放与之相关的各种资源,因此建议在不需要的时候尽量及时关闭已经打开的设备。

2.6   音频设备文件

      对于Linux应用程序员来讲,音频编程接口实际上就是一组音频设备文件,通过它们可以从声卡读取数据,或者向声卡写入数据,并且能够对声卡进行控制,设置采样频率和声道数目等等。

/dev/sndstat

      设备文件/dev/sndstat是声卡驱动程序提供的最简单的接口,通常它是一个只读文件,作用也仅仅只限于汇报声卡的当前状态。一般说来,/dev/sndstat是提供给最终用户来检测声卡的,不宜用于程序当中,因为所有的信息都可以通过ioctl系统调用来获得。 Linux提供的cat命令可以很方便地从/dev/sndstat获得声卡的当前状态:

safrans@safrans-desktop:~$ cat /dev/sndstat

/dev/dsp

      声卡驱动程序提供的/dev/dsp是用于数字采样(sampling)和数字录音(recording)的设备文件,它对于Linux下的音频编程来讲非常重要:向该设备写数据即意味着激活声卡上的D/A转换器进行放音,而向该设备读数据则意味着激活声卡上的A/D转换器进行录音。目前许多声卡都提供有多个数字采样设备,它们在Linux下可以通过/dev/dsp1等设备文件进行访问。

      DSP是数字信号处理器(Digital Signal Processor)的简称,它是用来进行数字信号处理的特殊芯片,声卡使用它来实现模拟信号和数字信号的转换。声卡中的DSP设备实际上包含两个组成部分:在以只读方式打开时,能够使用A/D转换器进行声音的输入;而在以只写方式打开时,则能够使用D/A转换器进行声音的输出。严格说来,Linux下的应用程序要么以只读方式打开/dev/dsp输入声音,要么以只写方式打开/dev/dsp输出声音,但事实上某些声卡驱动程序仍允许以读写的方式打开/dev/dsp,以便同时进行声音的输入和输出,这对于某些应用场合(如IP电话)来讲是非常关键的。

      在从DSP设备读取数据时,从声卡输入的模拟信号经过A/D转换器变成数字采样后的样本(sample),保存在声卡驱动程序的内核缓冲区中,当应用程序通过read系统调用从声卡读取数据时,保存在内核缓冲区中的数字采样结果将被复制到应用程序所指定的用户缓冲区中。需要指出的是,声卡采样频率是由内核中的驱动程序所决定的,而不取决于应用程序从声卡读取数据的速度。如果应用程序读取数据的速度过慢,以致低于声卡的采样频率,那么多余的数据将会被丢弃;如果读取数据的速度过快,以致高于声卡的采样频率,那么声卡驱动程序将会阻塞那些请求数据的应用程序,直到新的数据到来为止。

      在向DSP设备写入数据时,数字信号会经过D/A转换器变成模拟信号,然后产生出声音。应用程序写入数据的速度同样应该与声卡的采样频率相匹配,否则过慢的话会产生声音暂停或者停顿的现象,过快的话又会被内核中的声卡驱动程序阻塞,直到硬件有能力处理新的数据为止。与其它设备有所不同,声卡通常不会支持非阻塞(non-blocking)的I/O操作。

      无论是从声卡读取数据,或是向声卡写入数据,事实上都具有特定的格式(format),默认为8位无符号数据、单声道、8KHz采样率,如果默认值无法达到要求,可以通过ioctl系统调用来改变它们。通常说来,在应用程序中打开设备文件/dev/dsp之后,接下去就应该为其设置恰当的格式,然后才能从声卡读取或者写入数据。

/dev/audio

     /dev/audio类似于/dev/dsp,它兼容于Sun工作站上的音频设备,使用的是mu-law编码方式。如果声卡驱动程序提供了对/dev/audio的支持,那么在Linux上就可以通过cat命令,来播放在Sun工作站上用mu-law进行编码的音频文件:

safrans@safrans-desktop:~$ cat audio.au > /dev/audio

      由于设备文件/dev/audio主要出于对兼容性的考虑,所以在新开发的应用程序中最好不要尝试用它,而应该以/dev/dsp进行替代。对于应用程序来说,同一时刻只能使用/dev/audio或者/dev/dsp其中之一,因为它们是相同硬件的不同软件接口。

/dev/mixer

     在声卡的硬件电路中,混音器(mixer)是一个很重要的组成部分,它的作用是将多个信号组合或者叠加在一起,对于不同的声卡来说,其混音器的作用可能各不相同。运行在Linux内核中的声卡驱动程序一般都会提供/dev/mixer这一设备文件,它是应用程序对混音器进行操作的软件接口。混音器电路通常由两个部分组成:输入混音器(input mixer)和输出混音器(output mixer)。

      输入混音器负责从多个不同的信号源接收模拟信号,这些信号源有时也被称为混音通道或者混音设备。模拟信号通过增益控制器和由软件控制的音量调节器后,在不同的混音通道中进行级别(level)调制,然后被送到输入混音器中进行声音的合成。混音器上的电子开关可以控制哪些通道中有信号与混音器相连,有些声卡只允许连接一个混音通道作为录音的音源,而有些声卡则允许对混音通道做任意的连接。经过输入混音器处理后的信号仍然为模拟信号,它们将被送到A/D转换器进行数字化处理。

     输出混音器的工作原理与输入混音器类似,同样也有多个信号源与混音器相连,并且事先都经过了增益调节。当输出混音器对所有的模拟信号进行了混合之后,通常还会有一个总控增益调节器来控制输出声音的大小,此外还有一些音调控制器来调节输出声音的音调。经过输出混音器处理后的信号也是模拟信号,它们最终会被送给喇叭或者其它的模拟输出设备。对混音器的编程包括如何设置增益控制器的级别,以及怎样在不同的音源间进行切换,这些操作通常来讲是不连续的,而且不会像录音或者放音那样需要占用大量的计算机资源。由于混音器的操作不符合典型的读/写操作模式,因此除了openclose两个系统调用之外,大部分的操作都是通过ioctl系统调用来完成的。与/dev/dsp不同,/dev/mixer允许多个应用程序同时访问,并且混音器的设置值会一直保持到对应的设备文件被关闭为止。

      为了简化应用程序的设计,Linux上的声卡驱动程序大多都支持将混音器的ioctl操作直接应用到声音设备上,也就是说如果已经打开了/dev/dsp,那么就不用再打开/dev/mixer来对混音器进行操作,而是可以直接用打开/dev/dsp时得到的文件标识符来设置混音器。

/dev/sequencer

      目前大多数声卡驱动程序还会提供/dev/sequencer这一设备文件,用来对声卡内建的波表合成器进行操作,或者对MIDI总线上的乐器进行控制,一般只用于计算机音乐软件中。

 

3       ALSA Example

一个典型的声音程序使用PCM的程序通常类似下面的伪代码:

打开回放或录音接口

设置硬件参数(访问模式,数据格式,信道数,采样率,等等)

while 有数据要被处理:

PCM数据(录音)

或 写PCM数据(回放)

关闭接口

 

      设置参数,参数设置不当将会导致音频设备无法正常工作。在设置参数前,我们需要了解一下各个参数的含义以及一些基本概念。

样本长度(sample):样本是记录音频数据最基本的单位,常见的有8位和16位。

通道数(channel):该参数为1表示单声道,2则是立体声。

(frame):桢记录了一个声音单元,其长度为样本长度与通道数的乘积。

采样率(rate):每秒钟采样次数,该次数是针对桢而言。

周期(period):音频设备一次处理所需要的桢数,对于音频设备的数据访问以及音频数据的存储,都是以此为单位。

交错模式(interleaved):是一种音频数据的记录方式,在交错模式下,数据以连续桢的形式存放,即首先记录完桢1的左声道样本和右声道样本(假设为立体声格式),再开始桢2的记录。而在非交错模式下,首先记录的是一个周期内所有桢的左声道样本,再记录右声道样本,数据是以连续通道的方式存储。不过多数情况下,我们只需要使用交错模式就可以了。

我们将在下文中看到一些可以工作的代码。我建议您在你的Linux系统上测试运行这些代码。查看输出并尝试修改推荐的代码。和本文相关的所有实例清单可以从FTP中获取:ftp.ssc.com/pub/lj/listings/issue126/6735.tgz

 

3.1   Example1. Display Some PCM Types and Formats.

 

 

         Example1显示了一些ALSA使用的PCM数据类型和参数。首先需要做的是包括头文件。这些头文件包含了所有库函数的声明。其中之一就是显示ALSA库的版本。

这个程序剩下的部分的迭代一些PCM数据类型,以流类型开始。ALSA为每次迭代的最后值提供符号常量名,并且提供功能函数以显示某个特定值的描述字符串。你将会看到,ALSA支持许多格式。

这个程序必须链接到alsalib库,通过在编译时需要加上-lasound选项。有些alsa库函数使用dlopen函数以及浮点操作,所以您可能还需要加上-ldl,-lm选项。

下面是该程序的Makefile:

  

 

 

在电脑上运行,结果如下:

 

  

3.2   Example2. Opening PCM Device and Setting Parameters.

 

  

     example2打开hw:0,1PCM设备,设置一些硬件参数并且打印出最常用的硬件参数值。它并不做任何回放或录音的操作。snd_pcm_open打开hw:0,1PCM设备并设置访问模式为PLAYBACK。这个函数返回一个句柄,这个句柄保存在第一个函数参数中。该句柄会在随后的函数中用到。像其它函数一样,这个函数返回一个整数。如果返回值小于0,则代码函数调用出错。如果出错,我们用snd_errstr打开错误信息并退出。

为了设置音频流的硬件参数,我们需要分配一个类型为snd_pcm_hw_param的变量。分配用到函数宏snd_pcm_hw_params_alloca。下一步,我们使用函数snd_pcm_hw_params_any来初始化这个变量,传递先前打开的PCM流句柄。

接下来,我们调用API来设置我们所需的硬件参数。这些函数需要三个参数:PCM流句柄,参数类型,参数值。我们设置流为交错模式,16位的样本大小,2个信道,44100bps的采样率。对于采样率而言,声音硬件并不一定就精确地支持我们所定的采样率,但是我们可以使用函数snd_pcm_hw_params_set_rate_near来设置最接近我们指定的采样率的采样率。其实只有当我们调用函数snd_pcm_hw_params后,硬件参数才会起作用。

程序的剩余部分获得并打印一些PCM流参数,包括周期和缓冲区大小。结果可能会因为声音硬件的不同而不同。

运行该程序后,做实验,改动一些代码,设置不同的硬件参数然后观察结果的变化。

在电脑上运行,结果如下:

 

  

  

3.3   Example3.Simple Sound Playback.

  

     example3扩展了之前的示例。向声卡中写入了一些声音样本以实现声音回放。在这个例子中,我们从标准输入中读取数据,每个周期读取足够多的数据,然后将它们写入到声卡中,直到5秒钟的数据全部传输完毕。

     这个程序的开始处和之前的版本一样---打开PCM设备、设置硬件参数。我们使用由ALSA自己选择的周期大小,申请该大小的缓冲区来存储样本。然后我们找出周期时间,这样我们就能计算出本程序为了能够播放5秒钟,需要多少个周期。 

     在处理数据的循环中,我们从标准输入中读入数据,并往缓冲区中填充一个周期的样本。然后检查并处理错误,这些错误可能是由到达文件结尾,或读取的数据长度与我期望的数据长度不一致导致的。

     我们调用snd_pcm_writei来发送数据。它操作起来很像内核的写系统调用,只是这里的大小参数是以帧来计算的。我们检查其返回代码值。返回值为EPIPE表明发生了underrun,使得PCM音频流进入到XRUN状态并停止处理数据。从该状态中恢复过来的标准方法是调用snd_pcm_prepare函数,把PCM流置于PREPARED状态,这样下次我们向该PCM流中数据时,它就能重新开始处理数据。如果我们得到的错误码不是EPIPE,我们把错误码打印出来,然后继续。最后,如果写入的帧数不是我们期望的,则打印出错误消息。

     这个程序一直循环,直到5秒钟的帧全部传输完,或者输入流读到文件结尾。然后我们调用snd_pcm_drain把所有挂起没有传输完的声音样本传输完全,最后关闭该音频流,释放之前动态分配的缓冲区,退出。

     我们可以看到这个程序没有什么用,除非标准输入被重定向到了其它的文件。尝试用设备/dev/urandom来运行这个程序,该设备产生随机数据:

 ./test </dev/urandom

随机数据会产生5秒钟的白色噪声。然后,尝试把标准输入重定向到设备/dev/null/dev/zero上,并比较结果。改变一些参数,例如采样率和数据格式,然后查看结果的变化。

3.4   Example4. Simple Sound Recording.

  

     example4类似于example3中的程序,除了这里的程序是做声音的抓取(录音)。当打开PCM设备时我们指定打开模式为SND_PCM_STREAM_CPATURE。在主循环中,我们调用snd_pcm_readi从声卡中读取数据,并把它们写入到标准输出。同样地,我们检查是否有overrun,如果存在,用与前例中相同的方式处理。

     运行example4的程序将录制将近5秒钟的声音数据,并把它们发送到标准输出。你也可以重定向到某个文件。如果你有一个麦克风连接到你的声卡,可以使用某个混音程序(mixer)设置录音源和级别。同样地,你也可以运行一个CD播放器程序并把录音源设成CD。尝试运行程序4并把输出定向到某个文件,然后运行程序3播放该文件里的声音数据:

./listing4>sound.raw

./listing3<sound.raw

如果你的声卡支持全双工,你可以通过管道把两个程序连接起来,这样就可以从声卡中听到录制的声音:

./listing4 | ./listing3

同样地,您可以做实验,看看采样率和样本格式的变化会产生什么影响。

3.5   高级特性

      在前面的例子中,PCM流是以阻塞模式操作的,也就是说,直到数据已经传送完,PCM接口调用才会返回。在事件驱动的交互式程序中,这样会长时间阻塞应用程序,通常是不能接受的。ALSA支持以非阻塞模式打开音频流,这样读写函数调用后立即返回。如果数据传输被挂起,调用不能被处理,ALSA就是返回一个EBUSY的错误码。

许多图形应用程序使用回调来处理事件。ALSA支持以异步的方式打开一个PCM音频流。这使得当某个周期的样本数据被传输完后,某个已注册的回调函数将会调用。

      这里用到的snd_pcm_readisnd_pcm_writei调用和Linux下的读写系统调用类似。字母i表示处理的帧是交错式(interleaved)的。ALSA中存在非交互模式的对应的函数。Linux下的许多设备也支持mmap系统调用,这个调用将设备内存映射到主内存,这样数据就可以用指针来维护。ALSA也运行以mmap模式打开一个PCM信道,这允许有效的零拷贝(zero copy)方式访问声音数据。

4       ALSA移植

alsa的移植请参考以下网址:

http://blog.csdn.net/jiajie961/archive/2010/11/30/6045507.aspx

http://blog.csdn.net/jiajie961/archive/2010/12/01/6047077.aspx

 

  

5       Preference

1. http://blog.csdn.net/jiajie961/archive/2010/11/30/6045507.aspx

2. http://blog.csdn.net/jiajie961/archive/2010/12/01/6047077.aspx

3. http://www.alsa-project.org/main/index.php/Main_Page

4. http://www.linuxjournal.com/article/6735

5. http://apps.hi.baidu.com/share/detail/7910583