1．OSS简介OSS的层次结构非常简单，应用程序通过API（定义于 <soundcard.h>）访问OSS driver，OSS driver控制声卡。如下图所示：
 声卡中主要有两个基本装置：Mixer和CODEC(ADC/DAC)。Mixer用来控制输入音量的大小，对应的设备文件为/dev/mixer；CODEC用来实现录音（模拟信号转变为数字信号）和播放声音（数字信号转变为模拟信号）的功能，对应的设备文件为/dev/dsp。
开发OSS应用程序的一般流程是：
1）包含OSS头文件：#include <soundcard.h>
2）打开设备文件，返回文件描述符
3）使用ioctl设置设备的参数，控制设备的特性
4）对于录音，从设备读（read）
5）对于播放，向设备写（write）
6）关闭打开的设备
2．缓冲区设置的性能分析在设置驱动内部的缓冲区时，存在一个矛盾：在声卡驱动程序中，为了防止抖动的出现，保证播放的性能，设置了内部缓冲区-DMA buffer。在播放时，应用程序通过驱动程序首先将音频数据从应用程序缓冲区-APP buffer，写入到DMA buffer。接着，由DMA控制器把DMA buffer中的音频数据发送到DAC（Digital-Analog Converter）。某些时刻CPU非常的繁忙，比如正在从磁盘读入数据，或者正在重画屏幕，没有时间向DMA buffer放入新的音频数据。DAC由于没有输入新的音频数据，导致声音播放的间断，这就出现了声音的抖动现象。此时，需要将DMA buffer设置的足够大，使得DAC始终有数据播放。但是，DMA buffer的增大使得每次从APP buffer拷贝的时间也变长，导致了更大的播放延迟。这对于那些延迟敏感的应用场合，如与用户有交互的音频应用程序，就会出现问题。
对于这个矛盾，可以从两个不同的方面分别着手解决。驱动程序采用多缓冲(Multi-buffering)的方式，即将大的DMA buffer分割成多个小的缓冲区，称之为fragment，它们的大小相同。驱动程序开始时只需等待两个fragment满了就开始播放。这样可以通过增加fragment的个数来增加缓冲区的大小，但同时每个fragment被限制在合适的大小，也不影响时延。音频驱动程序中的多缓冲机制一般会利用底层DMA控制器的scatter-gather功能。
另一方面，应用程序也可指导驱动程序选择合适大小的缓冲区，使得在没有抖动的情况下，时延尽可能的小。特别的，应用程序将驱动程序中的缓冲通过mmap映射到自己地址空间后，会以自己的方式来处理这些缓冲区（与驱动程序的不一定一致），这时应用程序往往会先根据自己的需要设置驱动程序中内部缓冲区的大小。
在OSS的ioctl接口中，SNDCTL_DSP_SETFRAGMENT就是用来设置驱动程序内部缓冲区大小。具体的用法如下：
1
2
3
4
5
| int param;
param = ( 0x0004 << 16) + 0x000a;
if (ioctl(audio_fd, SNDCTL_DSP_SETFRAGMENT, ¶m) == -1) {
...error handling...
}
|
参数param由两部分组成：低16位为fragment的大小，此处0x000a表示fragment大小为2^0xa，即1024字节；高16位为fragment的数量，此处为0x0004，即4个fragement。设置好fragment参数后，通过ioctl的SNDCTL_DSP_SETFRAGMENT命令调整驱动程序中的缓冲区。
为了给音频程序的开发者展示缓冲区配置对播放效果的影响，我们将对缓冲区配置与播放性能的关系进行测试。下面首先介绍测试的环境，包括测试方法的原理和测试结果的含义；接着针对两种情况进行测试，并解释测试的结果。
测试环境
测试是在PC机上进行的，具体的测试环境参见下表。
项目参数CPUPIII 800内存256M SDRAM硬盘ST 80G UDMA显卡TNT2 m64 16M声卡主板集成（工作在44.1KHz，立体声，16bit的模式）内核Linux kernel 2.4.20（Redhat 9.0）
测试软件（latencytest）由两部分组成：音频播放测试程序、系统运行负载模拟程序。（注：latencytest软件主要目的是测试内核的时延，但这里作为对不同缓冲配置进行比较的工具。）
音频播放测试程序的工作流程见下面的代码。为了保证音频播放在调度上的优先性，音频播放测试程序使用SCHED_FIFO调度策略（通过sched_setscheduler()）。
1
2
3
4
5
6
7
8
| while(1)
{
time1=my_gettime();
通过空循环消耗一定的CPU时间
time2=my_gettime();
write(audio_fd,playbuffer,fragmentsize);
time3=my_gettime();
}
|
my_gettime返回当前的时刻，在每个操作的开始和结束分别记录下时间，就可以得到操作所花费的时间。audio_fd为打开音频设备的文件描述符，playbuffer是应用程序中存放音频数据的缓冲区，也就是APP buffer，fragmentsize为一个fragment的大小，write操作控制向驱动写入一个fragment。空循环用来模拟在播放音频时的CPU运算负载，典型的例子是合成器（synthesizer）实时产生波形后，再进行播放（write）。空循环消耗的时间长度设置为一个fragment播放时延的80%。
相关指标的计算方法如下：
- 1） 一个fragment的播放时延(fragm.latency) = fragment大小/(频率*2*2)。以fragment大小为512字节和以上的测试环境为例，一个fragment时延 = 512/(44100*2*2) = 2.90ms[44100表示44.1KHz的采样频率，第一个2表示立体声的两个声道，第二个2表示16bit为2个字节]。
- 2） 一个fragment的传输时延 = 将一个fragment从APP buffer拷贝到DMA buffer的时延。
- 3） time3-time1 = 一次循环持续的时间 = 空循环消耗的CPU时间 + 一个fragment的传输时延。
- 4） time2-time1 = 空循环消耗的实际CPU时间(cpu latency)。
为了模拟真实的系统运行情况，在测试程序播放音频数据的同时，还运行了一个系统负载。一共设置5种负载场景，按顺序分别是：
- 1） 高强度的图形输出（使用x11perf来模拟大量的BitBlt操作）
- 2） 高强度对/proc文件系统的访问（使用top，更新频率为0.01秒）
- 3） 高强度的磁盘写（向硬盘写一个大文件）
- 4） 高强度的磁盘拷贝（将一个文件拷贝到另一个地方）
- 5） 高强度的磁盘读（从硬盘读一个大文件）
针对不同的系统负载场景，测试分别给出了各自的结果。测试结果以图形的形式表示，测试结果中图形的含义留待性能分析时再行解释。
性能分析
下面，我们分别对两种缓冲区的配置进行性能比较，
- 1） 情况1：fragment大小为512字节，fragment个数为2。
- 2） 情况2：fragment大小为2048字节，fragment个数为4。
为了看懂测试结果，需要了解测试结果图形中各种标识的含义：
- 1） 红线：全部缓冲区的播放时延。全部缓冲区播放时延 = 一个fragment时延 x fragment的个数。对于测试的第一种情况，全部缓冲区时延 = 2.90ms x 2 = 5.8ms。
- 2） 白线：实际的调度时延，即一次循环的时间（time3-time1）。如果白线越过了红线，则说明所有的缓冲区中音频数据播放结束后，应用程序仍然没有来得及将新的数据放入到缓冲区中，此时会出现声音的丢失，同时overruns相应的增加1。
- 3） 绿线：CPU执行空循环的时间（即前面的time2-time1）。绿线的标称值为fragm.latency x 80%。由于播放进程使用SCHED_FIFO调度策略，所以如果绿线所代表的时间变大，则说明出现了总线竞争，或者是系统长时间的处于内核中。
- 4） 黄线：一个fragment播放时延。白线应该接近于黄线。
- 5） 白色的between +/-1ms：实际的调度时延落入到fragm.latency +/-1ms范围的比例。
- 6） 白色的between +/-2ms：实际的调度时延落入到fragm.latency +/-2ms范围的比例。
- 7） 绿色的between +/-0.2ms：CPU的空循环时延波动+/-0.2ms范围的比例（即落入到标称值+/-0.2ms范围的比例）。
- 8） 绿色的between +/-0.1ms：CPU的空循环时延波动+/-0.1ms范围的比例（即落入到标称值+/-0.1ms范围的比例）。
第一种情况的缓冲区很小，每个fragment只有512字节，总共的缓冲区大小为2 x 512 = 1024字节。1024字节只能播放5.8ms。根据OSS的说明，由于Unix是一个多任务的操作系统，有多个进程共享CPU，播放程序必须要保证选择的缓冲区配置要提供足够的大小，使得当CPU被其它进程使用时（此时不能继续向声卡传送新的音频数据），不至于出现欠载的现象。欠载是指应用程序提供音频数据的速度跟不上声卡播放的速度，这时播放就会出现暂停或滴答声。因此，不推荐使用fragment大小小于256字节的设置。从测试结果中看到，不管使用那种系统负载，都会出现欠载的现象，特别是在写硬盘的情况下，一共发生了14次欠载（overruns = 14）。
当然，对于那些实时性要求高的音频播放程序，希望使用较小的缓冲区，因为只有这样才能保证较小的时延。在上面的测试结果我们看到了欠载的现象，但是，这并不完全是缓冲区过小所导致的。实际上，由于Linux内核是不可抢占的，所以无法确知Linux在内核中停留的时间，因此也就无法保证以确定的速度调度某个进程，即使现在播放程序使用了SCHED_FIFO调度策略。从这个角度来说，多媒体应用（如音频播放）对操作系统内核提出了更高的要求。在目前Linux内核的情况下，较小的调度时延可以通过一些专门的内核补丁（low-latency patch）达到。不过我们相信Linux2.6新内核会有更好的表现。
第二种情况的缓冲区要大得多，总共的缓冲区大小为4 x 2048 = 8192字节。8192字节可以播放0.046秒。从测试的图形来看，结果比较理想，即使在系统负载较重的情况，仍然能够基本保证播放时延的要求，而且没有出现一次欠载的现象。
当然，并不是说缓冲区越大越好，如果继续选择更大的缓冲区，将会产生比较大的时延，对于实时性要求比较高的音频流来说，是不能接受的。从测试结果中可以看到，第二种配置的时延抖动比第一种配置要大得多。不过，在一般情况下，驱动程序会根据硬件的情况，选择一个缺省的缓冲区配置，播放程序通常不需要修改驱动程序的缓冲区配置，而可以获得较好的播放效果。 |
