Linphone学习之 Oss

1．OSS简介

OSS的层次结构很是简单，应用程序经过API（定义于 <soundcard.h>）访问OSS driver，OSS driver控制声卡。以下图所示：

oss结构

声卡中主要有两个基本装置：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就是用来设置驱动程序内部缓冲区大小。具体的用法以下：

int param; param = ( 0×0004 << 16) + 0x000a; if (ioctl(audio_fd, SNDCTL_DSP_SETFRAGMENT, &param) == -1) { …error handling… }

参数param由两部分组成：低16位为fragment的大小，此处0x000a表示fragment大小为2^0xa，即1024字节；高16 位为fragment的数量，此处为0×0004，即4个fragement。设置好fragment参数后，经过ioctl的 SNDCTL_DSP_SETFRAGMENT命令调整驱动程序中的缓冲区。

为了给音频程序的开发者展现缓冲区配置对播放效果的影响，咱们将对缓冲区配置与播放性能的关系进行测试。下面首先介绍测试的环境，包括测试方法的原理和测试结果的含义；接着针对两种状况进行测试，并解释测试的结果。

测试环境

测试是在PC机上进行的，具体的测试环境参见下表。

项目 参数 CPU PIII 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()）。

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大小/(频率22)。以fragment大小为512字节和以上的测试环境为例，一个fragment时延 = 512/(4410022) = 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。 测试结果1(2×512.html) 2） 状况2：fragment大小为2048字节，fragment个数为4。 测试结果2(4×2048.html)

为了看懂测试结果，须要了解测试结果图形中各类标识的含义：

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秒。从测试的图形来看，结果比较理想，即便在系统负载较重的状况，仍然可以基本保证播放时延的要求，并且没有出现一次欠载的现象。

固然，并非说缓冲区越大越好，若是继续选择更大的缓冲区，将会产生比较大的时延，对于实时性要求比较高的音频流来讲，是不能接受的。从测试结果中 能够看到，第二种配置的时延抖动比第一种配置要大得多。不过，在通常状况下，驱动程序会根据硬件的状况，选择一个缺省的缓冲区配置，播放程序一般不须要修 改驱动程序的缓冲区配置，而能够得到较好的播放效果。

3．非阻塞写（non-blocking write）

若是播放程序写入的速度超过了DAC的播放速度，DMA buffer就会充满了音频数据。应用程序调用write时就会由于没有空闲的DMA buffer而被阻塞，直到DMA buffer出现空闲为止。此时，从某种程度来讲，应用程序的推动速度依赖于播放的速度，不一样的播放速度就会产生不一样的推动速度。所以，有时咱们不但愿 write被阻塞，这就须要咱们可以知道DMA buffer的使用状况。

for (;;) { audio_buf_info info; /* Ask OSS if there is any free space in the buffer. / if (ioctl(dsp,SNDCTL_DSP_GETOSPACE,&info) != 0) { perror(“Unable to query buffer space”); close(dsp); return 1; }; / Any empty fragments? / if (info.fragments > 0) break; / Not enough free space in the buffer. Waste time. */ usleep(100); };

以上的代码不停的查询驱动程序中是否有空的fragment（SNDCTL_DSP_GETOSPACE），若是没有，则进入睡眠 （usleep(100)），此时应用程序作其它的事情，好比更新画面，网络传输等。若是有空闲的fragment（info.fragments > 0），则退出循环，接着就能够进行非阻塞的write了。

4．DMA buffer的直接访问（mmap）

除了依赖于操做系统内核提供更好的调度性能，音频播放应用程序也能够采用一些技术以提升音频播放的实时性。绕过APP buffer，直接访问DMA buffer的mmap方法就是其中之一。

咱们知道，将音频数据输出到音频设备一般使用系统调用write，可是这会带来性能上的损失，由于要进行一次从用户空间到内核空间的缓冲区拷贝。这 时，能够考虑利用mmap系统调用，得到直接访问DMA buffer的能力。DMA控制器不停的扫描DMA buffer，将数据发送到DAC。这有点相似于显卡对显存的操做，你们都知道，GUI能够经过mmap将framebuffer（显存）映射到本身的地 址空间，而后直接操纵显存。这里的DMA buffer就是声卡的framebuffer。

理解mmap方法的最好方法是经过实际的例子， 代码1（list1.c）。

代码中有详细的注释，这里只给出一些说明。

PlayerDMA函数的参数samples指向存放音频数据的缓冲，rate/bits/channels分别说明音频数据的采样速率、每次采样的位数、声道数。

在打开/dev/dsp之后，根据/rate/bits/channels参数的要求配置驱动程序。须要注意的是，这些要求并必定能获得知足，驱动程序要根据本身的状况选择，所以在配置后，须要再次查询，获取驱动程序真正使用的参数值。

在使用mmap以前，要查看驱动程序是否支持这种模式（SNDCTL_DSP_GETCAPS）。使用SNDCTL_DSP_GETOSPACE得知驱动选择的framgment大小和个数，就能够计算出所有DMA buffer的大小dmabuffer_size。

mmap将dmabuffer_size大小的DMA buffer映射到调用进程的地址空间，DMA buffer在应用进程的起始地址为dmabuffer。之后就能够直接使用指针dmabuffer访问DMA buffer了。这里须要对mmap中的参数作些解释。

音频驱动程序针对播放和录音分别有各自的缓冲区，mmap不能同时映射这两组缓冲，具体选择映射哪一个缓冲取决于mmap的prot参数。 PROT_READ选择输入（录音）缓冲，PROT_WRITE选择输出（播放）缓冲，代码中使用了PROT_WRITE|PROT_READ，也是选择 输出缓冲。（这是BSD系统的要求，若是只有PROT_WRITE，那么每次对缓冲的访问都会出现segmentation/bus error）。

一旦DMA buffer被mmap后，就不能再经过read/write接口来控制驱动程序了。只能经过SNDCTL_DSP_SETTRIGGER打开DAC的使能位，固然，先要关闭使能位。

DMA一旦启动后，就会周而复始的扫描DMA buffer。固然咱们老是但愿提早为DMA准备好新的数据，使得DMA的播放始终连续。所以，PlayerDMA函数将mmap后的DMA buffer分割成先后两块，中间设置一个界限。当DMA扫描前面一块时，就填充后面一块。一旦DMA越过了界限，就去填充前面一块。

使用mmap的问题是，不是全部的声卡驱动程序都支持mmap方式。所以，在出现不兼容的状况下，应用程序要可以转而去使用传统的方式。

最后，为了能深刻的理解mmap的实现原理，咱们以某种声卡驱动程序为例，介绍了其内部mmap函数时具体实现。 代码2(list2.c)

audio_mmap()是实现mmap接口的函数，它首先根据mmap调用的prot参数（vma->vm_flags），选择合适的缓冲 （输入仍是输出）；vma->vm_end – vma->vm_start为须要映射到应用进程地址空间的大小，必须和DMA buffer的大小（s->fragsize * s->nbfrags）一致；若是DMA buffer尚未创建，则调用audio_setup_buf(s)创建；接着对全部的fragment，从映射起始地址开始 （vma->vm_start），创建实际物理地址与映射的虚拟地址之间的对应关系（remap_page_range）。最后设置mmap标志 （s->mapped = 1）。

5．结束语

固然，除了上面所讨论的问题之外，音频应用的开发还有不少实际的问题须要去面对，好比多路音频流的合并，各类音频文件格式的打开等等。

OSS音频接口存在于Linux内核中许多年了，因为在体系结构上有许多的局限性，在Linux 2.6内核中引入了一种全新的音频体系和接口——ALSA（Advanced Linux Sound Architecture），它提供了不少比OSS更好的特性，包括彻底的thread-safe和SMP-safe，模块化的设计，支持多个声卡等等。 为了保持和OSS接口的兼容性，ALSA还提供了OSS的仿真接口，使得那些为OSS接口开发的大量应用程序仍然可以在新的ALSA体系下正常的工做。