　　测试软件（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大小/(频率*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。测试结果1(2x512.html)
　　2）情况2：fragment大小为2048字节，fragment个数为4。测试结果2(4x2048.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_WRITEPROT_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体系下正常的工作。

上一页 [1] [2] [3] 下一页

上一篇:做了make_recover却不能恢复的解决办法

下一篇:用Apache+Tomcat创建与管理Web服务器

深入OSS（Open Sound System）的开发相关文章：

·EZ-USB 68013A开发指南

·Visual Studio 2005集成开发环境图解

·windows 2003服务器配置VPN实现各种网络环境VSS协同开发

·在.NET 应用程序中用System.Web.Mail 发送电子邮件

·openssl的man中文文档

·兵之利器软件开发辅助工具纵览

·XPCOM--LINUX下的组件开发技术

·开发WDM型的USB设备驱动程序

·DirectX游戏开发入门

·samba和openldap结合实战

深入OSS（Open Sound System）的开发相关软件：

·孙鑫VC++从入门到精通开发详解视频教程FLASH版

·中国少年儿童智力开发百科全书(上中下)高清PDF全彩图书

·深入理解计算机系统电子杂志 PDF

·Cooolsoft MP3 Sound Cutter （音频截取工具） V1.41 绿色版

·Sound ForgeV8.0d build 128

·Sony Sound Forge9.0a

·嵌入式系统应用开发技术 wmv 视频教程

·盟军敢死队-深入敌后

·PHP+MySQL网络开发技术

·全脑开发大师IQ EQ MQ

特别声明：本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载，但请务必注明出处和原始作者。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站，我们表示深深的谢意。如果本站转载的文章有版权问题请联系编辑人员，我们尽快予以更正。
[打印本页] [关闭窗口] 转载请注明来源：http://www.vipcn.net

	\| 帮助(？) \| 版权声明 \| 友情连接 \| 关于我们 \| 信息发布
Copyright 2007 www.vipcn.net All Rights Reserved.	鄂ICP备05000083号Powered by:viphot