原文：
译言版：
教学贴（PulseAudio,ESD和ALSA,OSS的关系）：
由于实在是不喜欢译言的，觉得googletranslate的都比她们好……
我之所以钻研linux内核，只想是晓得为何我的系统还是没有声音……
linux音频系统构架问题来历已久……远远比你想象的复杂。假如你想理清从读取音频文件到最终从你的耳机中播放下来这一过程中所用到的技术之间的关系的话，纸上的结布光足以像面酱面一样混乱，而你根本找不到任何头绪。
这是由于，音频系统本身就比其他构架愈加复杂。OSI模型每一层都有自己的作用域和功能，每一层几乎不会有任何交集，所以你绝对不会遇到任何混乱情况。并且，在linux音频系统上，却上演着这样的事情：没有明晰的底层，各类音频技术各自为政。linux的音频系统构架有点像地幔构造，时常就水灾一下，要不就火山爆发一下，下层结构则要用力遮掩发生的一切。
OpenSoundProtocol（开放声音合同？），原先拿来内核和声卡通讯的（驱动），而且如今却成了alsa的一个胶合层（也不错，驱动声卡）。alsa兼具底层和硬件通讯，为应用程序提供api，即负责混缩，又负责硬件资源调用，多声道支持，环绕立体声输出等，甚至还要负责mp3解码（哪些时侯alsa负责mp3解码了？我out了）。所以当街多发行版使用PulseAudio或则Gstreamer时侯，错误就不断的发生了…
输入:PulseAudio,Jack,GStreamer,Xine,SDL,ESD
输出:Hardware,OSS
首先，让我们从了解alsa（AdvancedLinuxSoundArchitecture,中级linux音频构架）开始。alsa直接和内核通讯，并提供音频插口功能以供调用。并且，虽然alsa做了“比争当一个驱动程序”更多的事情：为系统混缩，为其他程序提供音频输出输出插口，为程序员提供api。他的目标似乎要同Windows的ASIO或则OSX的CoreAudio一样，作为一个底层而稳定的后台程序运行。
原本alsa是设计成为oss的继任者的，值得幸好的是，oss并没有真的死亡，凭着着alsa的兼容层重生了。所以可以简单的把alsa理解为声卡的驱动层。实际驱动声卡的还是oss。声卡须要加载前缀为snd_的内核驱动模块，以在发声风波时驱动声卡发声。这也就是你须要linux声卡驱动的缘由，这也可能是你电脑不出声音的缘由…
辛运的是，大部份的发行版都早已手动配置好相关设备以及驱动模块，alsa负责提供api给应用程序，应用程序可以调用api发声。最初这个设计是给oss用的～（当时大部份驱动都是这么），并且会引起声卡独占问题（即只有一个程序可以发声，其他程序只能步入队列等待）。
alsa须要一个软件部件检测声卡并管理声卡。当有两个或多个程序须要同时发声，alsa则进行软混缩——如果你的声卡支持，则使用声卡硬混缩。alsa最多可以同时管理8路的声频硬件，还可以同时支持mid特点。其实这个特点要取决于你的计算机硬件，所以随着硬件的发展，这个特点不是变得这么重要了。
alsa和其他驱动不同之处是它的可制订性。也正是由于高度的可制订性，致使linux音频系统构架越来越复杂。通过配置文件（/usr/share/alsa/alsa.conf）你可以管理一切——不论是混缩形式，输出设备选择，取样率，比特深度，还是实时音质。
alsa因其透明性、高效性和灵活性使之成为了Linux音频系统的标准，也成为了几乎其他所有的音频构架和硬件通讯的桥梁。
输入:GStreamer,Xine,ALSA
输出:ALSA,Jack,ESD,OSS
假如你觉得让alsa当后台就万无一失，那可就大错特错了。alsa似乎可以管理硬件，而且软件层却是其力所不及的地方。
这就是pulse，联接软件和硬件，远程计算机和本地计算机。它可以像alsa那样处理本地音频流，可以更灵活的处理远程计算机的音频流并在本地发声。由于其灵活性，可用性，早已被诸多linux发行版所采用（为何arch还是alsa而不是pulse，囧）。
附加疗效和alsa一样，高度的灵活性带来了高度的复杂性。并且虽然pulse的问题更为复杂，由于pulse是面向用户设计的，所以用户的错误配置可能轻易的造成故障。所以即便是ubuntu，系统也尽量不会让用户修改其配置文件。
当你使用面板上的音量调节工具调节音量时，实际上你调节的是个虚拟设备——你调节pulse的虚拟设备，pulse调节alsa，alsa反馈给pulse，pulse再反馈给虚拟设备……（多苦恼啊）
似乎pulse没有给linux音频系统带来哪些增益？所以反对的声音不绝于耳（她们认为和alsa相比就是重复造轮子？）。他没有使已有的操作上去更简单（指alsa），也没有带来更好地音质（本子想要hifi疗效？），然而它带来了几个特别重要的特点。首当其冲就是混缩特点。
假如所有的程序都使用pulse，一切都将显得美好上去。开发者们不用再考虑系统复杂性，由于pulse是跨平台的。但正是由于这般，所以有那么多其他的音频解决方案的主要诱因之一。
不像alsa那样，pulse可以跨平台，运行在不同的操作系统上，包括POSIX标准的unix-like系统和谷歌的Windows。也就是说呢，假如你写的程序使用pulse而不是alsa，这么移植上去会十分轻松。
事情似乎并不简单，由于在linux上，pulse依赖于alsa，pulse把自身模拟成输出设备，供alsa调用。这点有点和Jack相像，处在alsa和桌面之间，使用管线来传输数据。
不同于jack，它不主动添加或删掉音频源，所以你可以对所有输出的音频程序音量等进行分控，哈哈，起码用这个特点你可以让这些吵人的网站全部静音（firefox静音吗？flashblock就好了嘛～）
输入:Phonon
输出:ALSA,PulseAudio,Jack,ESD
算上gstreamer，linux的音频系统愈加复杂了……因为gstreamer有点像pulse，没有哪些新的特点。他是诞生在pulse之前，并且拥有更多的开发者。看上去更象是gnome专属的一个多媒体框架。它是为数不多的可以安装并使用解码器的构架之一。他也是GTK开发者的首选，使用gstreamer你甚至可以为PalmPre进行程序开发。
gstreamer介于软件层和音频输入层之间，优先于pulseaudio。gstreamer与众不同之处在于他不只是个音频处理框架，通过安装解码器，你还可以通过他来播放音频视频文件。
比如播放mp3，一般是下载相应的gstreamer解码器并安装。linux下惟一一个官方授权的商业版的FluendoMP3解码器，是一个gstreamer插件，虽然mpeg，h264等也都是这么。
输入:PulseAudio,GStreamer,ALSA,
输出:OSS,FFADO,ALSA
拥有pulse开放性等特征，通过管线传输音频流，最终使用输出设备输出音频。jack是个中间层，音频和程序的远程进程讯号等同，这促使应用程序可以通过组件构建。
最好的反例就是虚拟录音，应用程序在录音的同时可以对音频进行处理，并把处理好的数据通过一个虚拟设备“输出”到应用程序。实际录音情况中有可能使通过网路或则线缆等，jack同样对输入的音频流进行处理。
jack是jack音频联接工具包的简称，因为其低延时，面向底层设计，所以不会发生由于须要处理过多数据而平缓的情况。而且假如须要使用jack，音频程序须要进行相应的编码，专为jack而设计。jack不像alsa，pulse那样简单，他须要运行在系统的最高优先级，并且须要专门的设备输入。
在jack兼容的程序中，你自由的选择音频输入方法，比如你可以直接使用audacity录制当前vlc输出的音频。或则你可以通过JackRack，完善包括ping延后、多道混响和语言编码等多种实时疗效的应用程序来发送它。
jack对于多媒体工作站是不二之选。Ardour就是使用jack作为输入输出组件。jack是这么之出众，甚至你在mac上也能见到他的身影。
输入:Jack
输出:Audiohardware
许多专业设备都是通过“火线”连接到pc的。这样做有好多优点，火线传输速度快，并且可以为外设供电。好多台式机和电脑都有火线接口百度网盘LINUX，它是这么稳定而成熟。在外边，你可以通过电脑的火线接口录制音频，回到工作室再导出工作站中。
与usb不同，它是专用于音频输入输出的接口，拥有自己的通讯合同，无须安装驱动程序。这般的复杂性，致使alsa不能胜任。所以它使用专属于自己的胶合层。
原本，这是个叫FreeBOB的项目，这得益于许多火线音频设备都是基于相同的硬件合同。FFADO是FreeBOB的继任者，提供更多特点，并为其他类型的火线接口设备提供支持。
2009年底，他发布了第二版，包含了对许多类似Alesis、Apogee、ART、CME、Echo、Edirol、Focusrite、M-Audio、Mackie、Phonic和Terratec的单元的支持。由于不能确保所有的硬件都能在这个平台上工作，所以选购前你须要进行测试（livecd测试ati主板？lol），好多厂商也提供FFADO开发者设备以支持其改进和驱动建立。
FFADO另一个特点是整合了dsp芯片的混缩驱动，你可以通过图形界面设置输入输出，以及音质等。不同于alsa的软混缩，你可以真正的对硬件进行控制，做到真正的0延时，这对现场录音等需求大大有助。
和alsa等其他构架不同linux 音频解码器，jack仅仅对其支持的硬件进行处理，没有对alsa或则pulse提供插口，除非你用alsa取代jack，否则你没法使用jack正常的进行音频播放。并且好多专业设备对jack支持良好，所以jack是你的最优选择。
输入:Phonon
输出:PulseAudio,ALSA,ESD
假如说linux音频发展像月球史，那xine就处在三叠纪纪。它如同个腐儒，你仍能从好多播放器中发觉它的身影，所以好多linux发行版一直捆绑着xine。
xine成立之初，设计分为后端和前端，后端用于和用户交互，前端处理多媒体。得益于封装的解码库，它可以播放包括AVI、Matroska和Ogg以及它们包含的数十种格式，比如AAC、Flack、MP3、Vorbis和WMA。
由于它依赖于库实现，所以xine被开发成一个多媒体框架，库的开发，致使xine在法律容许范围内对多媒体文件提供最好的支持。xine可以和alsa，pulse通讯，好多程序也可以调用xine，比如totme-xine。同时xine也是kde的Phonon默认前端，所以不论是Amarok还是Kaffeine，都能见到他的踪迹。
输入:Qt和KDE程序
输出:GStreamer,Xine
跨平台是他最大的优势。开发者可以用Qt在Linux上编撰一个音乐播放器，之后可以重编译给OSX和Windows使用，而无须要考虑音乐是怎样播放的、使用的音频硬件的兼容性怎么，或则最终操作系统会怎样处理音频那些问题。Qt的Phonon手动完成音频传送，比如手动传送到OSX的CoreAudio的API中，或则Windows的DirectSound中。
在Linux平台上（不同于先前的KDE版本），得益于其透明的编解码器的支持，Phonon传递音频给GStreamer。phonon正在渐渐从Qt的框架中剥离。
这个构架遭到最大的批评就是它过分简单，没有任何新的特点，不过看样子KDE4中，还是会将它保留在构架中的。
其实还有其他好多冷门的音频技术，比如ESD、SDL和PortAudio。
ESD是声音启发守护进程（EnlightenmentSoundDaemon），它在以前很长的一段时间里曾是Gnome桌面的默认声音服务。后来，Gnome开始使用libcanberra（它本身可以和ALSA、GStreamer、OSS和PulseAudio通讯）linux是什么系统，ESD在2009年4月被彻底舍弃支持。在kde上esd也是悲剧。由于大部份人都是使用kde4，所以phonon取代了esd。渐渐的esd掉入历史长河…
SDL仍然欣欣向荣的发展着。由于早已是用他开发了上百款跨平台游戏，所以SDL库的音频输出组件仍然支持良好，具有大量新的特点，但是成熟而稳定。
PortAudio也是一个跨平台音频库，它把SGI、Unix和Beos加入到可能的终端混缩器中。使用PortAudio的最著名的应用程序就是Audacity音频编辑器了，由于使用了portaudio，致使它音频输出遇见了问题，jack支持也遇见了bug（audacity得不偿失啊）
OSS，开放声音系统（OpenSoundSystem）。它早已被从linux2.4以后的版本中剥离linux 音频解码器，然而他依旧存在……主要诱因是有太多的程序依然在使用它。不像alsa，它可以在除Linux的平台上运行。它甚至还有个FreeBSD版本……（老当益壮～）在1992年，它可以说是一个挺好的系统，而且如今它几乎被alsa替换。OSS定义了Linux下音频的工作方法，非常是音频设备要通过ioctl分支访问，比如通过/dev/dsp。ALSA提供了一个OSS兼容层来让这些使用OSS的程序仍然可以使用alsa标准。OSS项目以前作过开源和专利开发的尝试，现今仍作在为4项后端技术（4FrontTechnologies）的商业开发而努力，并在2009年11月发布了OSS4.2的2002版。
