漫谈Linux下的音频问题(转)

转自 http://www.kunli.info/2009/03/24/linux-sound-issue/

现今的互联网，比较Linux和Windows的战争贴基本都成月经贴了。一群群激进的用户不断轰轰烈烈攻击对方，可是不多有能拿出新鲜干货的，基本上双方理由我如今都能背得了。在攻击Linux的阵营中，一条很重要的理由就是：硬件驱动不完善。

今天要谈的声卡问题，就是属于“驱动”这类问题。我在我工做用笔记本，家用笔记本，工做用服务器两台，上面都装过Ubuntu，无一例外遇到声音的 问题。去ubuntu.org看看，抱怨声卡问题的呐喊不绝于耳，不管是菜鸟，中鸟仍是老鸟。固然不光是ubuntu，debian系的，Redhat系 的（包括Fedora），据我所知都能找到相似的问题。个人博客以前也有关于声音问题的文章。究竟是什么缘由致使Linux这么难发声呢？

Ubuntu官方Forum上有一篇很是好的帖子谈了这一点。本文实际上是该帖原意的中文表达。但这只是从理论的高度上来分析的，若是你是遇到问题了，经过搜索引擎来到了这里，请直接看本文“总结部分”，这部分的reference post基本上就就是Ubuntu 音频问题大全了。

如今让咱们从下到上对这个问题来一次bottom-up的分析吧。

首先，Linux社区面对的最大也是最现实的现状，就是获得的支持太少了。从芯片的层次讲，每个OEM商都有能力去配置线路的链接，以适应本身生 产机器的需求，好比一个厂商能够在机器上搞两个麦克风接口，一个在前面板，一个在后面板；而另外一个厂商则可能会反过来配置，诸如此类。商家们搞完个性化， 弄好Windows驱动，就万事大吉开庆功会了，可怜咱们的Linux社区不得不针对不一样机器的不一样配置进行处理，而后还要保证用户们能搞清楚本身的机器 是什么样的配置状况。

从声卡自己的层次讲。目前，台式机最流行的也就是创新的声卡了。最让人沮丧的就是，创新的Linux驱动历来就没有作好过。创新本身也没有办法，干 脆本身就放弃了这块的开发，于去年11月宣布公开发布Sound Blaster X-Fi和X-Fi Titanium系列的Linux 32/64-bit驱动源代码，说好听点，叫作众人拾材火焰高，说很差听点，就是爷不玩了，谁爱用谁开发去。固然也有一些支持比较好的，好比C- Media的一些板载，或者就是那种高端和专业的声卡了。

是否是以为很沮丧？Linux的问题就在这里，若是你哪天发现x厂商发布一款超级无敌牛逼限量发行1000套的硬件，而后你想入手给周边众多狐朋狗 友炫耀，而后很不幸你用的是Linux…….好吧，你必须祈祷在另外购买的999我的里面有至少2-3个Linux开发者，注意，不是所谓的高手。而后再 把硬件晾在家里几个月，等待驱动的推出…….

为何Linux的驱动就这么难开发呢？有人会说，驱动不就是一个翻译转换部件么，你声卡芯片不就是经过操做系统提供的底层服务和其余软件打交道的么，Linux源码都在那里了，这么多底层硬件驱动示例都在那里了，你怎么就开发不出来呢？

对，驱动的做用就是讲操做系统传递过来的命令和请求翻译并递交给声卡芯片，并将结果反馈。正由于这样，驱动就必须对硬件的细节很是了解。它必须知 道，并能检测，那些厂商对芯片的固件或者配置电路作了什么手脚，由于OEM们历来就懒得去发布这种信息。不然，就算是一样的芯片，也没法保证能适应不一样的 cable搭配。这个难度有多大呢？举个例子，就算是在一样的电脑的一样的芯片组上，新的7.1环绕声卡芯片的麦克风输入的线路，也多是和之前老的 5.1的配置过的声卡芯片的speaker输出用的是相同的线路。

如今，你知道问题所在了吧？做为驱动编写者，他们可让驱动去适应所能发现的全部的变化，可是，这就像一场猜谜游戏同样，没有尽头。因此，若是你拥 有一款比较特殊的声卡芯片并受困于其Linux驱动，请不要责备编写驱动的人，他们已经春蚕到死丝方尽了。现在，最有名且活跃的Ubuntu/linux 驱动编写团队要数ALSA和OSS了，对于他们所接受的这种极度困难的任务，咱们所能做的，应该是对他们的感谢。

讲完驱动，来说讲音频服务器吧。音频服务器就是位于驱动上面一层的东西，它负责给那些须要音频支持的应用提供内核服务，同时还调度这些服务，以及做 为其余硬件和软件交互的接口抽象。总的来讲，音频服务器就是用来链接应用程序到你的声卡，或者到网络，或者哪都不到，若是你配置错误的话。

刚才提到的ALSA和OSS团队，不只仅提供驱动，同时还提供音频服务器的服务。对于ALSA来讲，大多数提供的服务是单独运行的程序，好比 ESD，Enlightened Sound Demon，这玩意容许多个应用程序共享音频服务。这些程序已经开发了好几年了，可是都是以一种比较混乱的方式去解决已经观察到的缺陷。而OSS呢，则是 一个更老的项目，它是内核版本2.4.x时期的惟一认定音频系统，但以后一度被ALSA所替代，最后仍是存活了下来。关于二者的比较，请参考这里，我就不赘言了。后来OSS整个被重写，被命名为OSS4，如今还在活跃中。

接下来要介绍的Pulseaudio则是一个比较新的，彻底独立的音频服务器，只不过它利用的是ALSA的驱动，因此其目标就是替代ALSA的音频 服务器，包括全部的辅助部分，好比ESD。Pulseaudio同时还致力于提供ALSA当初很难提供的功能，好比网络广播，同步刷新多个声卡，分别控制 不一样应用程序的音量，以及不少别的好玩的功能。也有小道消息指出，Pulseaudio正在试验看可否工做在OSS4.1基础上。

而后咱们看看Jackd。不少人都把Jackd看做是音频服务器，这实际上是不许确的，它不是音频服务器，它的本质是音频链接套件。它的设计目标就是 围绕着提供某些应用所须要的服务来制定的。什么样的应用呢？是那些为音乐界专业大佬们服务的，这些应用的特殊之处在于，他们须要“实时”。好比说，它们可 能是位于支持实时内核/CPU优先访问和底层驱动访问的操做系统，用于减小在一些对时间狠敏感的活动中可能会出现的延迟或者中断，好比现场录制啊，表演啊 之类的。Jackd支持全部以JACK API套件编写的应用程序链接在一块儿，并同时被键盘或者midi设备本地或远程操做。因此说，Jackd很是适用于音乐家。但正是因为Jackd提供了如 此底层的控制，因此须要很仔细地去支配资源，并可能和一样但愿支配这些资源的音频服务器相冲突。考虑到这点，不管是ALSA OSS仍是Pulseaudio音频服务器，都提供了专门的模块负责和Jackd交互。

还有一个值得一提的玩意就是Phonon，这是一个新的音频服务器和应用API，专门用于KDE的，它能够兼容Pulseaudio以及ALSA驱动。具体的介绍请参加这篇文章。

讲完了音频服务器，接下来说讲接口。和驱动不同的是，音频服务器须要一个公用接口，用户才能和它们交互，并告知本身的需求。这个接口在哪里呢？就 在菜单里面的System/Preferences/Sound里面，打开看看。在这里，你能够指定将系统的声音送往音频服务器，或者直接送往驱动。前者 将致使音频服务器掌控一切，后者则会以驱动为主，服务器为辅。若是你选择autodetect，那第一个应用程序如何决定声音传输路径，以后的应用程序就 会遵循这个路径。若是你选择音频服务器，那么服务器会帮你管理，你能够在其之上作出一些调整。像ALSA就能够调用ESD来作声音共 享，Pulseaudio则会本身搞定这个。你还可让一个音频服务器来调用另外一个，好比让Pulseaudio做为ALSA的默认声卡，这样全部的 ALSA相关程序都会被重定向到Pulseaudio，这个过程，应用程序都是不知道的。

对于ALSA来说，它的接口包括了不少调音工具，最基本的就是在终端中调用的alsamixer，固然，你也能够用GUI版本的 alsamixer。在调音工具中，你能够经过各类各样的滑块和开关来控制声卡，固然有什么样的滑块和开关取决于你声卡的类型了。固然还有咱们更熟悉的音 量控制器，在这里也能够调节不少的选项。ALSA另外一个常用的接口就是asoundrc文件，你能够经过手工编辑它，也能够用asoundconf- gtk来调整选项。

对于Pulseaudio来讲，它自己对于驱动并无很深刻的控制，因此Pulseaudio也是调用的ALSA的调音工具。然 后，Pulseaudio能够控制主音量，声道的音量，应用程序的音量，等等。Pulseaudio的接口给用户提供了很详细的控制选项，在 Pulseaudio音量控制，也就是pavucontrol中，你能够看到你全部的输入输出设备，并能够将其中任何一个设置成默认设备。你还能够在不影 响应用程序操做的前提下控制任何程序的音量，以及它所使用的设备。在Pulse Audio Preferences (paprefs)中，你能够控制对你音频设备的网络访问，创建RTP服务器，甚至创建实际上几乎等同于实际硬件设备的虚拟设备。

正是因为这么多不一样的音频格式，不一样的音频服务器，为了保证音频仍然能正常工做，咱们最后不得不被带进一个充斥着音频滤波器，插件，包装器（wrapper）等等部件的时代。为了能让你们理解这些东西是怎么工做的，举大名鼎鼎的Amarok做为例子吧。

当你准备使用Amarok播放mp3的时候，Amarok会先看看你指定的文件，而后对本身说，好，如今我须要一些帮助，让我来看看谁能帮助我……好，xine引 擎，你小子有mp3插件，来把mp3文件转换成我能使用的东西，就是你了。Xine一看，哟，Amarok须要帮忙了，哪能见死不救呢，立马将mp3插件 双手奉上。Amarok会再对xine说，来，能帮我把数据送到Pulseaudio音频服务器那里去么？Xine天然不敢怠慢，立马找到 Pulseaudio，说，哥们，我这里有Amarok送过来的流数据，你能帮忙播放一下么？Pulseaudio说，没问题，拿过来吧。因而 Amarok获得消息，开始处理文件，送到xine，xine将其转换为pcm，并将pcm流送到Pulseaudio，Pulseaudio将流数据送 到alsa负责驱动的输出音频设备。若是这个设备是音箱或者耳机，pcm就会在alsa音量控制中被调整以让你能听到。因此最后整个流程是这样的

Amarok-xine-pulseaudio-alsa driver-sound card-speakers

只有xine能作这种后端处理的服务么？不是，另外一个大名远扬的服务就叫Gstreamer，喜欢用Rhythmbox的朋友估计不会对其陌生。事 实上Gstreamer和xine还能提供视频处理服务，只要有相应插件和滤波器支持就好了。这种方式对于程序开发者来讲更加具备吸引力，缘由就是他们只 须要编写和Gstreamer或者xine交互的接口，其余细节一概不关心。Gstreamer和xine同时也提供能够更改的配置文件。

对于插件来讲，程序开发者能够建立本身的插件，实际上，不管是gstreamer仍是xine，仍是alsa或者 oss 或者pulseaudio或者jack，都是很常见的程序插件。音频服务器也是包含了各类各样插件的，好比Pulseaudio就有不少被称为模块的插 件。ALSA也有不少包装到libasound2和libasound2-plugins的插件。插件是一个很好的东西，用户应该去尽量多地拥有他们， 这样才会有更好的灵活性，以及更宽的选择。

总结： 基本上，这就是音频系统在系统中工做的基础知识。但愿看到这里的朋友没有被搞昏头了。这篇文章只是给你们一个基础概念，并无牵涉到不少的细节。关于具体不少问题是怎么产生的，怎么解决，能够参考一下一些资料