PhononとKDEマルチメディアの今後

N.-Sanders（2006年5月9日（火））
シェア
次世代KDEの開発は、昨年8月のaKademyカンファレンスとQt 4 ツールキットのリリースで幕を開け、今、最盛期を迎えている。KateからKwinまで、KDEの各サブプロジェクトは、GNU/Linuxを代表するデスクトップの次回の全面的見直しに向けて、計画とコーディングの真っ最中だ。それぞれのKDEアプリケーションは、Qt4の利用と、KDEの外観、パワー、ユーザビリティの改善に伴い、コードの書き直しが必要になる。KDE 2および3のaRtsに代わる、KDE 4のマルチメディア・フレームワーク、Phononについても最新版の開発が発表されている。

aRtsは、何年もの間、開発者とユーザの不評を買っている。かなり前からメンテナンスがされておらず、オーディオプレーヤーのamaroKなど著名なKDEプロジェクトから見捨てられた時点で旧式になっていた。aRtsでは、フォーマットを気にせずに何十というオーディオ・コーデックの再生、ミキシング、編集ができ、ビデオまで扱えるという開発者にとって便利なGstreamerやHelixのような最近のマルチメディア・フレームワークに太刀打ちできない。GNOMEやEnlightenmentなど、ほかのデスクトップ環境は、既にこうしたフレームワークを標準として採用している。

aRtsが次世代KDEのマルチメディア・フレームワークとして役に立たないのは明らかだ。では、統合に重点を置くことを十分に強調しているKDEが、定評のある既存プロジェクトの採用に消極的なのはなぜだろうか。その答えは、こうしたフレームワーク向けのフロントエンドにある。このフロントエンドでは、PhononというAPIが提供する基本機能を備えた現在または将来のマルチメディア・バックエンドをサポートするためにプラグインを書くことができる。Phononは、Gstreamer、Helix、Xine, JACK、NMMをはじめとするバックエンド（aRtsも含む）の再生、ミキシング、エフェクトの機能から代表的なものうまく選定してサポートすると共に、簡潔で統一されたAPIによってこうした機能を開発者に提供する。複数のバックエンドがインストールされている場合、ユーザはどのバックエンドを使うかを設定でき、アプリケーション側に適切なバックエンドの選択や推奨を行わせることもできる。

PhononのAPIは、その他のアプリケーション・プログラミング・インターフェイスとまったく同様の働きをする。要するに、Phononは、KDEアプリケーションとメディア処理空間との間の抽象的なレイヤになる。KDEのアプリケーションがPhononの提供する関数の一覧を参照して呼び出しを行うと、選択されたバックエンドの呼び出し経路の切り換えをPhononが行う。Phononのプラグインは、原則として、こうしたPhonon APIの呼び出しを別のマルチメディア・フレームワークのAPIに変換する。この方法によって、開発者は、ビデオ再生、マイクからの録音、音量の調整といった操作を、ユーザがGstreamerとXineのどちらを好むかに関係なく動作する数行のコードを書くだけで行うことができる。

互いにかなり異なるとはいえ、本当にaRtsではなくPhononを使ってよいものか、というプログラマの不安を解消するためにもaRtsとPhononを比較しておこう。aRtsは、低レベルのメディア・フレームワークAPIを備えたサウンドサーバである。一方のPhononは、高レベルでタスク指向のAPIであり、低レベルの厄介な処理はバックエンドに任せている。Phononの主任開発者、Matthias Kretz氏は、以下のようなコード比較をしている。

「aRtsの場合は、URL用のPlayObjectを作成して出力につなげるために、いくつかのチェックと非同期処理が必要になる。Phononの場合、こうした処理はすべて裏側でやってくれる」 

aRtsを用いるサンプルコード

void ArtsPlayer::play(const FileHandle &file)
{
   if(!file.isNull())
       m_currentURL.setPath(file.absFilePath());

   if(m_server->server().isNull()) {
       KMessageBox::error(0, i18n("Cannot find the aRts soundserver."));
       return;
   }

   if(!m_playobject || !file.isNull()) {
       stop();

       delete m_playobject;
       m_playobject = m_factory->createPlayObject(m_currentURL, false);

       if(m_playobject->object().isNull())
           connect(m_playobject, SIGNAL(playObjectCreated()),
SLOT(playObjectCreated()));
       else
           playObjectCreated();
   }

   m_playobject->play();
}

void ArtsPlayer::playObjectCreated()
{
   setVolume(m_currentVolume);
}


Phonon APIを使ったより簡潔なコード
 

void ArtsPlayer::play(const FileHandle &file)
{
   if(file.isNull())
       return;
   m_currentURL.setPath(file.absFilePath());
   m_mediaobject->setUrl(m_currentURL);
   m_mediaobject->play();
}

また、Kretz氏によると、Phononには「グループ化されたアプリケーションのカテゴリごとに音量を操作するソフトウェア機能」が実装されるという。これにより、各種の通知音をバックグラウンドで静かなビープ音に抑えながら、複数のビデオプレーヤーの音量を上げることができるそうだ。これは、アプリケーションごとに別々の音量コントロールは不要だ考える人々にとっては歓迎すべきユーザビリティの向上だが、何の恩恵も感じない人もいるだろう。Kretz氏はさらに「Phononでは、アプリケーションに（バックエンドがそのようになっていれば）インプロセスでマルチメディア処理を行わせることができる。aRtsでは、artsdプロセス内の1つのスレッドですべてを実行していた」と話を続けた。現在のKDEでよく起こるのが、誤りのあるプログラムが1つ異常終了するとサウンドサーバ全体が停止してしまう問題だが、Phononでは解決されそうだ。

Kretz氏は、Phononと、KDE 4のハードウェア互換性に取り組むプロジェクトSolidの協力によって提供される、先進のハードウェア処理への取り組みに意気込みを示している。両者の協力によって、次のようなことが可能になる、と彼は説明してくれた。

  • コンピュータで作業していると、VoIP電話がかかってくる。
  • ユーザはUSBヘッドセットを探しながら、電話に出る。
  • 内蔵のマイクとスピーカで通話をしつつ、USBヘッドセットをコンピュータに差し込む。
  • SolidからPhononに新しいサウンドカードデバイスの通知が行われる。
  • 通信（Communication）カテゴリでは内蔵サウンドカードよりもUSBヘッドセットが優先されることをPhononが確認する。
  • VoIPプログラムがUSBヘッドセットに切り替えると、そのことを通知すると共に切り換えを取り消すボタンの表示されたパッシブポップアップが現れる。
  • 通知（Notification）カテゴリの優先出力先は内蔵サウンドカードになっているため、KDE標準の通知音は引き続きスピーカから出力される。

どのアプリケーション・カテゴリがどのハードウェア出力を使用するかの設定は、KControlモジュールを使って行われることになる見込みだ。Phononは、実際のマルチメディア処理やハードウェアとの入出力処理を独立したマルチメディア・フレームワークで行うため、aRtsよりも移植性が高くなるだろう。なお、移植性はKDE 4が注力している項目の1つだ。

それでも残る制約

しかし、Phononは万能ではない。開発者によってはバックエンドに直接アクセスする必要もあるだろう、とKretz氏は述べている。「Phonon APIの設計は、フレームワークに何ができるかではなく、アプリケーションには何が必要かを考えて行った。その結果として、Phononのバックエンドが提供すべき機能性を定義することになった。つまり、Phonon APIしか利用しない開発者は、バックエンドの実現に使われているメディア・フレームワークの能力をフルに活用することはできない。おそらく、次のような80対20の法則に従うのだろう。開発者の80%はPhononを使ってできることに満足してくれるはずだが、残り20%は、それ以上のパワー、コントロール、機能を必要とし、Phononと何らかのものを組み合わせて、あるいは、Phonon APIをまったく使わずに処理を行うことになる」

Phononは4月27日に発表されたばかりだが、作業の多くは既に完了している。Phononのロードマップでは、プロジェクト設計のほか、再生APIの設計案の作成まで終わっていることになっている。このAPIに対する初期の反応は上々で、そのシンプルさが評価されている。参考用のバックエンドも実装されており、ネットワーク統合マルチメディアミドルウェア（NMM）向けの動作モデルの第一弾が開発中である。Phononチームによるオーディオ・ビデオ・エフェクトおよびキャプチャのAPIに関する試験と動作確認に先立ち、これらのすべてが準備段階にある。Phononチームは、6月頃にKDE 4のコードベースにPhononが統合されると見込んでおり、続いてネットワークAPIに関する作業を進める予定だ。

Phononは、KDE 4を以前のものより設計面で優れたデスクトップ環境にするために開発者を呼び寄せるプロジェクトの1つに過ぎない。アイコンテーマSVGやヴィジュアルモチーフOxygen、ハードウェア・アクセラレーションによる動画を扱うCoolness、そしてデスクトップ検索エンジンTenorといった、KDEの存在感を増し、外観をより良いものにしようとする開発者たちによるコラボレーションとしてAppealプロジェクトがある。また、連携プロジェクトPlasmaでは「1984年のKDEデスクトップ環境と本質的に同じもの」を目指すという信念のもとでKDEのデスクトップ・インターフェイスの見直しを進めている。先に述べたSolidは、アプリケーションがUSBデバイスや無線ネットワークのようなハードウェアへの動的な接続と切断を管理するためのサポート機能の向上に取り組んでいる。こうしたプロジェクトから成るKDEの開発体制は、それぞれが独立したソフトウェアプロジェクトではなく、KDEが持つ多数の要素に特有のクオリティを強化しようと熱心に取り組み、必要であれば新しいコードを書く人々のグループである、という点でほかに類のないものだ。それぞれのプロジェクトでは、十分なマーケティング活動のおかげで、相当な熱気と議論が沸き起こっており、2007年はじめのKDE 4のリリースに向けて興奮と誇張気味の宣伝が広まっている。

原文