在TopLanguage问问题的时候，访问到了这个站点，网站介绍了四足机器人的建立过程。里面的一些内容很新鲜，长了不少见识。希望自己以后也能够有机会接触这样复杂的控制系统。上面的图是作者试图介绍嵌入式开发中目标环境和开发环境的关系的时候引用的。
前些时间，初次接触基于Linux系统的嵌入式开发 ，最先接触的就是交叉编译环境的建立。建立交叉编译环境，往往就是按照说明指导，在开发环境中安装支持特定微处理器架构的交叉编译工具。建立起来很容易，认清楚目标环境和开发环境的关系，才真正对理解应用程序和驱动程序开发和调试过程有帮助。交叉编译的理念是：在开发环境中进行源码编译，生成目标环境能够执行的二进制文件，并在目标环境中进行调试。这样做的好处不言而喻：精简了嵌入式系统，发挥了开发平台的优势。图中红色和灰色的部分是主机系统和目标系统必须相同的部分。安装交叉编译工具，其实就是在开发环境中安装compiler和lib。开发环境通过对代码的编译和连接，最终生成可在目标系统运行的执行文件。在驱动程序开发过程中，还需要提供配置好的内核源码资源作为source code，才能够生成供目标系统加载的模块。
前一篇文章介绍了OSS的概念，描述了OSS和Linux系统以及设备之间的关系，并简单介绍了一下使用OSS开发应用程序的一般流程。实际上，作为一个编程接口，在使用OSS操作声卡设备进行音频应用开发的时候，有一些需要特别理解和注意的技巧。本文主要对驱动内部缓冲区的设置问题谈谈自己的理解。
Linux音频数据传输机制
DMA技术在很大程度上增加了处理器读写音频数据的能力。在声卡驱动中，读写音频的过程实际上是音频数据与DMA Buffer数据交互的过程。在播放时，应用程序通过驱动程序首先将音频数据从应用程序缓冲区-APP buffer，写入到DMA buffer。接着，由DMA控制器把DMA buffer中的音频数据发送到DAC（Digital-Analog Converter）[1] 。在录音时，DMA控制器将ADC(Analog-Digital Converter) 输入的信号写入DMA buffer。接着，应用程序通过驱动程序将DMA buffer的数据读入APP buffer，完成录音的过程。
欠载和延时
在多任务应用程序中，CPU非常的繁忙，比如正在响应键盘事件，或者正在重画屏幕，没有时间向DMA buffer放入新的音频数据。DAC由于没有输入新的音频数据，导致声音播放的间断，这就出现了声音的抖动现象。这种由于播放不连续而产生的声音抖动现象就是欠载。欠载现象的产生主要是由于应用程序提供音频数据的速度跟不上声卡播放的速度而产生的。为了防止欠载现象的产生，就必须提供较大的DMA buffer 使得应用程序能够有足够的时间更新DMA buffer中的音频数据。原因可以参见PPT 的分析，T1=T2+T3(Max) 。
音频数据首先要装满 DMA buffer ，应用程序才能够通过驱动程序将DMA buffer的数据拷贝到APP buffer中进行处理。装满DMA buffer占用时间，就产生延时。DMA buffer 是音频延时产生的原因。在一些实时性要求高的应用中，比如要求声音即时录入、播放。延时量的大小是关键性的因素，应该尽可能的减少延时。
增加DMA buffer的大小，一方面，可以有效的防止欠载情况的出现。另一方面，增加了延时量。这是一个矛盾。
多缓冲机制（Multiple Buffering ）
为了解决这个矛盾，OSS采用了多缓冲机制。多缓冲机制将DMA buffer分为一定个数的Fragment。允许在第一个Fragment被写满时，将写满的Fragment数据拷贝到APP buffer进行处理。在保证DMA buffer较大（避免了欠载）的同时，减少了延时。Fragment的大小和数量可以在执行读写操作之前进行设置。设置的原则是保证DMA Buffer足够大，避免欠载。Fragment的大小足够小，减少延时。所以可以将Fragment大小设置的小一些，数目设定的多一些。
在实际的系统中，为了保证驱动工作的稳定性，Fragment的大小是有一定限制的，比如cirrus Ep9302处理器的OSS驱动，允许的最小设置量为2048 bytes。Fragment的数目也有一定的显示，比如Ep9302最大数目为64个。
一、数字音频
音频信号是一种连续变化的模拟信号，但计算机只能处理和记录二进制的数字信号，由自然音源得到的音频信号必须经过一定的变换，成为数字音频信号之后，才能送到计算机中作进一步的处理。数字音频系统通 过将声波的波型转换成一系列二进制数据，来实现对原始声音的重现，实现这一步骤的设备常被称为模/数转换器（A/D）。A/D转换器以每秒钟上万次的速率 对声波进行采样，每个采样点都记录下了原始模拟声波在某一时刻的状态，通常称之为样本（sample），而每一秒钟所采样的数目则称为采样频 率，通过将一串连续的样本连接起来，就可以在计算机中描述一段声音了。对于采样过程中的每一个样本来说，数字音频系统会分配一定存储位来记录声波的振幅， 一般称之为采样分辩率或者采样精度，采样精度越高，声音还原时就会越细腻。
对于音频编程而言，最重要的是理解声音数字化的两个关键步骤：采样和量化。采样就是每隔一定时间就读一次声音信号的幅度，而量化则是将采样得到的声音信号幅度转换为数字值，从本质上讲，采样是时间上的数字化，而量化则是幅度上的数字化。下面介绍几个在进行音频编程时经常需要用到的技术指标：
1. 采样频率
采样频率是指将模拟声音波形进行数字化时，每秒钟抽取声波幅度样本的次数。采样频率的选择应该遵循奈奎斯特（Harry Nyquist）采样理论：如果对某一模拟信号进行采样，则采样后可还原的最高信号频率只有采样频率的一半，或者说只要采样频率高于输入信号最高频率的两 倍，就能从采样信号系列重构原始信号。正常人听觉的频率范围大约在20Hz~20kHz之间，根据奈奎斯特采样理论，为了保证声音不失真，采样频率应该在 40kHz左右。常用的音频采样频率有8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等，如果采用更高的采样频率，还可以达到DVD的音质。
2. 量化位数
量化位数是对模拟音频信号的幅度进行数字化，它决定了模拟信号数字化以后的动态范围，常用的有8位、12位和16位。量化位越高，信号的动态范围越大，数字化后的音频信号就越可能接近原始信号，但所需要的存贮空间也越大。
3. 声道数
声道数是反映音频数字化质量的另一个重要因素，它有单声道和双声道之分。双声道又称为立体声，在硬件中有两条线路，音质和音色都要优于单声道，但数字化后占据的存储空间的大小要比单声道多一倍。
二、声卡驱动
出于对安全性方面的考虑，Linux下的应用程序无法直接对声卡这类硬件设备进行操作，而是必须通过内核提供的驱动程序才能完成。在Linux上进行音频编程的本质就是要借助于驱动程序，来完成对声卡的各种操作。
对硬件的控制涉及到寄存器中各个比特位的操作，通常这是与设备直接相关并且对时序的要求非常严格，如果这些工作都交由应用程序员来负责，那么对声卡的编程将变得异常复杂而困难起来，驱动程序的作用正是要屏蔽硬件的这些底层细节，从而简化应用程序的编写。目前Linux下常用的声卡驱动程序主要有两种：OSS 和ALSA。
最 早出现在Linux上的音频编程接口是OSS（Open Sound System），它由一套完整的内核驱动程序模块组成，可以为绝大多数声卡提供统一的编程接口。OSS出现的历史相对较长，这些内核模块中的一部分 （OSS/Free）是与Linux内核源码共同免费发布的，另外一些则以二进制的形式由4Front Technologies公司提供。由于得到了商业公司的鼎力支持，OSS已经成为在Linux下进行音频编程的事实标准，支持OSS的应用程序能够在绝大多数声卡上工作良好。
虽 然OSS已经非常成熟，但它毕竟是一个没有完全开放源代码的商业产品，ALSA（Advanced Linux Sound Architecture）恰好弥补了这一空白，它是在Linux下进行音频编程时另一个可供选择的声卡驱动程序。ALSA除了像OSS那样提供了一组内 核驱动程序模块之外，还专门为简化应用程序的编写提供了相应的函数库，与OSS提供的基于ioctl的原始编程接口相比，ALSA函数库使用起来要更加方 便一些。ALSA的主要特点有：
* 支持多种声卡设备
* 模块化的内核驱动程序
* 支持SMP和多线程
* 提供应用开发函数库
* 兼容OSS应用程序
ALSA 和OSS最大的不同之处在于ALSA是由志愿者维护的自由项目，而OSS则是由公司提供的商业产品，因此在对硬件的适应程度上OSS要优于ALSA，它能够支持的声卡种类更多。ALSA虽然不及OSS运用得广泛，但却具有更加友好的编程接口，并且完全兼容于OSS，对应用程序员来讲无疑是一个更佳的选择。
什么是OSS
OSS（Open Sound System）是 unix（Linux）平台上一个统一的音频接口, 即只要音频处理应用程序按照OSS的API（API即应用程序接口：在这里API需要在驱动程序实现，通过驱动程序将硬件抽象为软件程序接口）来编写，那 么在移植到另外一个平台时，只需要重新编译即可。
以前，每个Unix厂商都会提供一个自己专有的API，用来处理音频。这就意味着为一种Unix 平台编写的音频处理应用程序，在移植到另外一种Unix平台上时，必须要重写。不仅如此，在一种平台上具备的功能，可能在另外一个平台上无法实现。但 是，OSS出现以后情况就大不一样了，只要音频处理应用程序按照OSS的API标准来编写，那么在移植到另外一个平台时，只需要重新编译即可。因 此，OSS提供了源代码级的可移植性。
OSS的层次结构非常简单，应用程序通过API（定义于 soundcard.h）访问OSS driver，OSS driver控制声卡。如下图所示：
OSS中的音频设备文件
音频编程接口实际上就是一组音频设备文件，通过它们可以从声卡读取数据，或者向声卡写入数据，并且能够对声卡进行控制，设置采样频率和声道数目等等。对于linux系统中的音频编程者而言，OSS主要包括两个主要的设备文件：/dev/dsp 和 /dev/mixer 。
/dev/dsp
声卡驱动程序提供的/dev/dsp是用于数字采样（sampling）和数字录音（recording）的设备文件，它对于Linux下的音频编程来讲非常重要：向该设备写数据即意味着激活声卡上的D/A转换器进行放音，而向该设备读数据则意味着激活声卡上的A/D转换器进行录音。
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/mixer
在声卡的硬件电路中，混音器（mixer）是一个很重要的组成部分，它的作用是将多个信号组合或者叠加在一起，对于不同的声卡来说，其混音器的作用可能各不相同（也就是说混音需要特定的硬件支持）。运行在Linux内核中的声卡驱动程序一般都会提供/dev/mixer这一设备文件，它是应用程序对混音器进行操作的软件接口。混音器电路通常由两个部分组成：输入混音器（input mixer）和输出混音器（output mixer）。
输入混音器负责从多个不同的信号源接收模拟信号，这些信号源有时也被称为混音通道或者混音设备。模拟信号通过增益控制器和由软件控制的音量调节器后，在不同的混音通道中进行级别（level）调制，然后被送到输入混音器中进行声音的合成。混音器上的电子开关可以控制哪些通道中有信号与混音器相连，有些声卡只允许连接一个混音通道作为录音的音源，而有些声卡则允许对混音通道做任意的连接。经过输入混音器处理后的信号仍然为模拟信号，它们将被送到A/D转换器进行数字化处理。
输出混音器的 工作原理与输入混音器类似，同样也有多个信号源与混音器相连，并且事先都经过了增益调节。当输出混音器对所有的模拟信号进行了混合之后，通常还会有一个总 控增益调节器来控制输出声音的大小，此外还有一些音调控制器来调节输出声音的音调。经过输出混音器处理后的信号也是模拟信号，它们最终会被送给喇叭或者其 它的模拟输出设备。对混音器的编程包括如何设置增益控制器的级别，以及怎样在不同的音源间进行切换，这些操作通常来讲是不连续的，而且不会像录音或者放音 那样需要占用大量的计算机资源。由于混音器的操作不符合典型的读/写操作模式，因此除了open和close两个系统调用之外，大部分的操作都是通过 ioctl系统调用来完成的。与/dev/dsp不同，/dev/mixer允许多个应用程序同时访问，并且混音器的设置值会一直保持到对应的设备文件被 关闭为止。
为了简化应用程序的设计，Linux上的声卡驱动程序大多都支持将混音器的ioctl操作直接应用到声音设备上，也就是说如果已经打开了/dev /dsp，那么就不用再打开/dev/mixer来对混音器进行操作，而是可以直接用打开/dev/dsp时得到的文件标识符来设置混音器。
音频编程
可以直接使用Unix的命令来放音和录音，命令cat /dev/dsp >xyz可用来录音，录音的结果放在xyz文件中；命令cat xyz >/dev/dsp播放声音文件xyz。用这种方式，可以检查dsp设备是否工作。
使用编程的方式操作这些设备的基本流程是：
1）包含OSS头文件：#include
2）打开设备文件，返回文件描述符
3）使用ioctl设置设备的参数，控制设备的特性
4）对于录音，从设备读（read）
5）对于播放，向设备写（write）
6）关闭打开的设备
我在这里写了一个应用程序的样本：查看。
推荐看一下这篇文章：深入OSS开发。 文章对缓冲区设置的性能分析等很值得学习和理解。
参考文章：
[1]:Linux音频编程指南
[2]:OSS–跨平台的音频接口简介
[3]:深入OSS开发
