PulseAudioに注目すべき理由(とPulseAudioの始め方)

 サウンドサーバのPulseAudioはLinuxのサウンド分野では比較的新参者だが、少なくとも2つのメジャーなディストリビューション(FedoraUbuntu)の次期リリースでデフォルトのセットアップとして採用されたので、ここで一度調べて理解しておく価値はあるだろう。

 Linux用のサウンドシステムを理解するのは少々ややこしいことだ。どのプロジェクト(少し挙げるだけでもALSA、OSS、ESD、aRts、JACK、GStreamerがある)も大ざっぱで似たような言葉でプロジェクトを説明しているし、多種多彩なパッケージの名前――alsaplayer-esd、libesd-alsa、alsa-oss、alsaplayer-jack、gstreamer-alsa、gstreamer-esd等々――は、まるできりのない組み合わせゲームのようだ。また、これらのコンポーネントがどのように組み合わさるのかを説明するのもなかなか難しい。例えばUbuntuのlibasound2-pluginsパッケージの説明には「ALSAライブラリ用プラグインのjackは、ALSAライブラリがJACK経由で再生やキャプチャを行なうことができるようにするためのものです。(jackdパッケージに含まれているjackd出力ドライバのalsaと混乱しないようにして下さい。alsaは、JACKデーモンがALSAライブラリ経由で再生できるようにするためのものです。)」とある。もちろん――混乱する人などいるわけがない――だろうか?

整理

 混乱を招きやすくなってしまっている原因は複数あって、(開発者フレンドリーではなく)ユーザフレンドリな文書の不足や、複数のプロジェクト間で目標が重複していることなどを挙げることができる。

 例えばALSA(Advanced Linux Sound Architecture)プロジェクトには、いくつかの独立したコンポーネントがある。その中には、サウンドカード用のカーネルのハードウェアドライバもあれば、ALSAのAPI(アプリケーション・プログラミング・インターフェース)をアプリケーションから利用可能にするライブラリなどもある。ハードウェアドライバはサウンドカードにサウンドを出力させるために必要だが、ライブラリはアプリケーションによって使われたり使われなかったりする。

 またKDEのサウンドライブラリであるaRtsには、サウンドサーバ(サウンドをアプリケーションから受け取ってハードウェアドライバに渡す低レベルのデーモン)も含まれていれば、様々なファイルやストリーム形式のエンコード/デコードといった高レベルな機能も含まれている。一方、GNOMEでの状況はもう少しすっきりとしていて、サウンドサーバはESD(Enlightened Sound Daemon)であり、コーデックは別個のライブラリ(GStreamer)が扱うようになっている。

 とは言え混乱の最大の原因は、ユーザ空間ALSAライブラリ、aRts、ESD、GStreamerなど、独自のAPIを提供しているオーディオプロジェクトがあまりに多く存在しているということだろう。先にも述べたように、どれを組み合わせても様々な点で重複してしまう。さらにそれらに加えて、ゲーム向けのSDLOpenAL、古い汎用アプリケーション向けのOSS(Open Sound System)、プロ級の低遅延操作向けのJACKなども存在する。

 挙げ句の果てには、サウンド機能を外部のライブラリに頼らずに、すべて内部的に行なうアプリケーションもある。中でも最も有名なものとしては、高機能メディア再生アプリケーションのXineMPlayerなどがある。これらは、ファイルのデコードから多重分離処理まで、何から何までアプリケーション自体の中で取り扱っている。

 PulseAudioがどの部分に当てはまるのかは、個々の処理が切り分けて取り扱われる、GNOMEのシステムを用いて説明するのが最も簡単だ。GNOMEのRhythmboxなどのアプリケーションは、サウンドファイルの圧縮形式から生のサウンドデータへのデコードをGStreamerに依存している。次にGStreamerがそのサウンドデータをESDに渡して、ESDがそれをALSAハードウェアドライバに渡す。

 上記の状況に当てはめると、PulseAudioはパイプラインの他の部分に影響を与えることなくESDに置き換わることができる。ただし他のプレイヤーを使う場合には、上記の例には含まれていない、ALSAユーザ空間ライブラリも使用されるかもしれない。その場合にもやはりPulseAudioは、パイプラインの中でカーネルレベルのハードウェアドライバのすぐ上に位置することになる。PulseAudioを利用することにより階層が一つ増えることになるが、そうすることによりすべてのサウンドが同じサウンドサーバを経由することの利点を享受することができるようになる。

 そして、そこがポイントだ――ユーザ空間ALSA APIやaRtsやJACKを使うように書かれているアプリケーションもあれば、サウンドを内部的に扱うように書かれているアプリケーションもある――しかしすべてのサウンドが単一のハンドラを経由するようにすれば、制御しやすく、衝突が起こりにくく、予想外のことも起こりにくくなる。