最 新 技 術 情 報Technology Update

1716

DSPを使用したオーディオ処理

DSPアーキテクチャ

マルチメディア・ソフトウェア・スタックへのインテグレーション

ヘテロジニアス・マルチコアにおけるオーディオ処理の複雑さを解消

概要オーディオ処理に要求される性能は、上昇の一途をたどっています。以前はメインCPUの余ったサイクルでオーディオ処理を十分に実行できていましたが、最近ではBlu-ray™ディスクの24ビット/192kHz HD（High-Definition）オーディオ・ストリームのデコードや、9.1チャネルのPro Logic® IIzストリームのポストプロセッシングに非常に高い性能が要求されます。そこで考えられるのは、DesignWare ARC AS211SFX/AS221BDオーディオ・プロセッサなど、1つ以上のオーディオ専用DSP（Digital Signal Processor）にCPUの処理をオフロードする方法です。しかしそれではシステム設計が複雑になり、ハードウェアとソフトウェアの両方で多くの課題が発生します。本稿では、まずこれらの課題に言及し、いくつかのアーキテクチャ・ソリューションをご提案します。また、処理のオフロードによって発生する複雑さ以外にも、一般的なLinux®ベース･システムとAndroid™ベース・システムへのオーディオ・ソフトウェアのインテグレーション例を挙げながら、オーディオ処理ソフトウェアを大規模なマルチメディア/製品ソフトウェア・スタックに組み込む方法についてご説明します。

なお、本稿はソフトウェアの面から解説したものですが、ハードウェアとシステムの面を解説したホワイトペーパーも同時に公開しています[1]。併せてお読みいただくと、ハードウェアとソフトウェアの両方で構成されたインテグレーション済みオーディオ・サブシステム・ソリューションの利点をよりよくご理解いただけます。

はじめに

オーディオ処理をメイン・プロセッサからDSPにオフロードするアプローチは、システムに新しいプログラマブル・コアを1つ追加することを意味します。最近はマルチコア・システムに対する理解も深まっていますが、ヘテロジニアス・マルチコア・システム（汎用のメインCPUに、面積と消費電力を最適化したオーディオ処理専用のDSPを追加した構成）向けのソフトウェアを開発するのはまだまだ困難です。

対称型マルチプロセッサ（SMP）システムの場合、システムの複雑さはオペレーティング・システムによってほとんど隠蔽されますが、ヘテロジニアス・マルチプロセッサ・システムの場合は下層のハードウェア・アーキテクチャを意識しながら、その構成に合わせてコードを修正する必要があります。具体的には、ソフトウェアを汎用コアとDSPコアの間で分割し、メイン・コアからDSPを制御できるように修正を加え、圧縮オーディオと非圧縮オーディオのサンプルをDSPとメインCPUの間で交換できるようにしなければなりません。しかし、オーディオ・ドメインの要件に合わせてソフトウェア・インフラストラクチャを最適化すれば、マルチコアの細部を隠蔽でき、オーバーヘッドの増加も防げるため、シングルコアやSMPアーキテクチャと同じくらい簡単に、効率的なヘテロジニアス・マルチコア・システムを実現できます。

ソフトウェア・インフラストラクチャによって、見かけ上オーディオ・ソフトウェアがメインCPU上でローカルに実行されているようにしても、最先端のオーディオ・システム設計で直面する課題がすべて解決するわけではありません。通常、デバイスにはコネクティビティやその他のメディア処理の機能がいくつもあり、オーディオ処理はその1つに過ぎません。したがって、オーディオ・ソフトウェアは全体的なマルチメディアと製品ソフトウェアのスタックにシームレスに統合できなければなりません。この役割を果たすのが、図2に示したアプリケーション・プロセッサ側のオーディオ・プラグイン・コンポーネントです。これは、DSP側のすべてのオーディオ処理のプロキシとして動作します。標準化されたインターフェイスがあればインテグレーションは容易ですが、細分化が進んだコンシューマ・エレクトロニクス市場では、唯一絶対の標準規格は存在しません。

しかも、既存の標準規格やマルチメディア・フレームワークの多くは、処理をDSPにオフロードすることを考慮して開発されていません。クロノス・グループのOpenMAX-IL規格[2]は非常によく知られた業界標準規格ですが、主なターゲットは携帯機器であり、それ以外のコンシューマ・セグメントではあまり採用実績がありません。しかも、この規格の現行バージョンは多くのアプリケーションにとって必要以上に複雑であり、ほとんどの場合（ヘテロジニアス）マルチコア・アーキテクチャ向けに最適化されていません。その他の選択肢として、独自の内製ソリューションも数多く存在しますが、OpenMAXと同様にオープンな選択肢もいくつかあります。

Linuxの世界で最も有名なGStreamer[3]は、完全な機能を備えたクロス・プラットフォームのマルチメディア・フレームワークで、コンシューマ・エレクトロニクス機器での採用が広がっています。Androidの領域では、Google™/Open Handset Alliance™のソリューションの一環として提供されるStagefrightマルチメディア・フレームワーク[4]が勢力を伸ばしています。本稿では、これら3つの一般的なマルチメディア・フレームワークの概要をご説明した後、各フレームワークの長所と短所を簡潔にご説明します。また、面積と消費電力を最適化したDSP（ARC AS211SFX/AS211BDオーディオ・プロセッサなど）に処理のほとんどをオフロードするオーディオ・ソフトウェア・スタックをSoCに組み込み、オーディオ処理性能の向上とシステム消費電力の削減というヘテロジニアス・アーキテクチャの利点を最大限に引き出す方法を、ソフトウェア・エンジニアの負担軽減の観点からご説明します。

ヘテロジニアス・マルチコア・アーキテクチャでソフトウェアによるオーディオ処理の複雑さを隠蔽するには、ホスト・プロセッサ（1つ以上のオーディオ

SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション

DSP をホスティングする汎用 CPU）で提供される API（Application Programming Interface）にいくつかの条件が求められます。

まず1つは、実行場所を意識しなくても良い環境をAPIが提供できることです。APIを使用するクライアント・ソフトウェアは、APIのサービスがCPUで実行されているのかDSPで実行されているのかを気にしなくてよいのが理想です。そうすれば、実際にはDSPで実行されていても、プログラマはそのことを意識せずにシングルコア・アーキテクチャの場合と同じような感覚でAPIを使用できます。つまり、ソフトウェアを通常と同じようにコーディングするだけでホスト・プロセッサの負荷が軽減され、DSPでリアルタイムのオーディオ処理が高速に実行されます。

APIに求められる2つ目の条件は、強力で柔軟であることです。APIは、プログラマに代わって低レベルの制御を行うことにより、使い勝手の良さ、高度な機能性、そして優れた伝達能力を最適なバランスで実現する必要があります。APIを上手に選ぶと、ヘテロジニアス・マルチコア実装の細部をクライアントから隠蔽できます。ただし、ヘテロジニアス・システムでAPIより下層の実装コードを改変する場合は、実装状況を全く意識しない作業というわけにはいきません。たとえば、ホストCPUのコンパイラでなくDSPクロス・コンパイラを使用するなど、ワークフローも異なってきます。したがってAPIは、そのAPIを使用するプログラマが、APIやその仕組みを修正・拡張しなくても目的のユースケースを実現化できるものでなければなりません。幸い、オーディオ処理やマルチメディア処理は、一般的に自然なAPIレベルで実行されます。オーディオ処理は、MP3デコードやサウンドのイコライズなど、オーディオ・データのストリームに対して特定の処理を実行する個々の機能を連結したチェーン（グラフ）によって実行します。APIレベルが一致するとクライアントはこれらの機能をインプリメントするストリーミング・コンポーネントをインスタンス化し、これらを連結することで処理グラフの形成と制御を行います。

APIに求められるもう1つの条件は、効率的な実装方式が可能であることです。オーディオ処理を複数のコアに分散させると、専用の演算リソースが増えて処理が高速化しますが、必然的に通信と同期のオーバーヘッドも生じます。これは、オーディオ・データをホストからDSPへ転送し、DSPで処理したオーディオをホストへ戻す必要があるためで、複数のDSPを使用する場合はDSP間でのオーディオ・サンプルのやりとりも必要になります。また、ホストからDSPへ制御コマンドを送信し、ステータスやイベント情報をホストに返す処理も最小限のレイテンシで行えなければなりません。この結果、デザインにはデータ・コピーとバッファリングを最小限に抑える要件が課せられます。これは、共有メモリーとコア間割り込みという、最小限のハードウェアによるサポートを追加するだけで実現できます。

効率、使い易さ、柔軟性、実行場所を意識しない環境の条件を満たしたソフトウェア・アーキテクチャを図3に示します。図の左側はホスト・プロセッサの、そして右側はDSPのソフトウェア・レイヤとコンポーネントをそれぞれ示しています。DSPのアーキテクチャはすべて共通です。

DSPソフトウェア・スタックは、3つのインフラストラクチャ・コンポーネントと任意の数のオーディオ処理コンポーネントで構成されます。最下層では、リアルタイム・オペレーティング・システムがマルチスレッディングとその他の基本的なOSサービスを提供します。シノプシスのDesignWare SoundWaveオーディオ・サブシステム[5]では、信頼性と効率を考慮してARC MQXを選択しています。次に、マルチメディア・ストリーミング・フレームワーク（MSF）がオーディオ処理コンポーネント用のランタイム環境を提供し、クライアント・ソフトウェアが目的の製品に固有のユースケースをインプリメントしたプレーヤー /レコーダー・アプリケーションを作成するための統一したAPIを提供します。このフレームワークは、すべてのオーディオ処理コンポーネントに必要な共通コードを外に出します。また、コンポーネント間でオーディオ・データ（サンプルまたはフレームを含んだパケット）を通信する機能を提供するとともに、バッファリングの処理、そしてEnd-of-Streamイベントや時間同期といったオーディオ固有の制御機能を提供します。DesignWare SoundWaveオーディオ・サブシステムでは、ARCオーディオ・プロセッサでのオーディオ処理に最適化したARC MSFを使用しています。このMSFはデータ・コピーやホスト・プロセッサの関与なしにコンポーネント間でのデータ・ストリーミングをローカル制御できるようにインプリメントしているため、オーディオ処理モジュールをカスタマ・アプリケーションに容易に組み込めるほか、強力で柔軟なAPIの条件も満たすことができ、効率的なマルチコア実装も実現します。図4は、MP3ファイル再生の処理グラフの生成方法を示したものです。ソース、デコーダ、シンクの各コンポーネントを作成、接続、開始してファイル・システムからMP3を読み出し、コンテンツをデコードし、デコードしたサンプルを出力デバイス・ドライバ経由でスピーカにレンダリングします。

実行場所を意識しない環境の役割を果たすのが、RPC/IPCコンポーネントです。IPC（プロセッサ間通信）コンポーネントが提供するメッセージ・パッシングAPIは物理的なインターコネクト媒体を抽象化します。たとえば共有メモリーを介した通信では、キャッシュ・コヒーレンシを維持するにはデータ・キャッシュをフラッシュして無効にしなければならない場合があります。さらに、IPCコンポーネントは割り込みハンドラやその他の低レベルな細部を処理してくれます。効率を重視して、共有メモリー・バッファ

ARC AS211SFX/AS221BDオーディオ・プロセッサ

図 1. デコードとポストプロセッシングを DSP にオフロードしたオーディオ処理

リーダ（ソースから読み出し）

デマルチプレクサ（コンテナの

フォーマットを解析）

図 2. ホスト・ソフトウェアへの DSP ソフトウェアのインテグレーション

図 3. ヘテロジニアス・マルチコア・オーディオ処理ソリューションのアーキテクチャ

図 4. MSF のソースコード例

ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション

ARC AS211SFX/AS221BDオーディオ・プロセッサ

メディア・プレーヤー・クライアント・アプリケーション

メディア・プレーヤー

リーダ

レンダラ

デコーダラッパ

ポストプロセッシングプラグイン

MSFフレームワーク（リモート・インプリメンテーションへのプロキシ）

ホスト・オペレーティング・システム

アプリケーション・プロセッサ

オーディオ・データ、制御RPC/IPC

MSFフレームワーク

MQX OS

RPC/IPC

デコーダ ポストプロセッシング

デマルチプレクサ デコーダ

次ページに続く

アプリケーション

ビデオ

グラフィックス

オーディオプラグイン

OS

アプリケーションプロセッサ

デコード +

エンコード

ソース +

シンク

ARC AS211SFX/AS221BDオーディオ・プロセッサ

ソフトウェア・インフラストラクチャ ドライバ

ペリフェラルとクロック

ポストプロセッシング

オーディオレンダリング

汎用CPU

オーディオDSP制御API 制御API

オーディオデコード

ポストプロセッシング

オーディオデコード // Step #1 – creating modules

msf_api_source_module_create(“Source”, … ,&source_module_id);msf_api_audio_api_module_create(“MP3 Decoder”, … , &audio_api_module_id);msf_api_sink_module_create(“Sink”, … , &sink_module_id);

// Step #2 – connecting modulesmsf_api_connect_pins(source_module_id, audio_api_module_id, …);msf_api_connect_pins(audio_api_module_id, sink_module_id, …);

// Step #3 – starting data processing by sending START_PLAYBACK messagemsf_api_message_send_to_module(source_module_id,　　　　　　　　　　MSF_MESSAGE_CONTROL_CMD_START_PLAYBACK, …);

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

&A

検証

編S

upport Q&

Aフ

ィジ

カル

編S

upport Q&

A論

理合

成編

New

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

ン

最 新 技 術 情 報Technology Update

1716

DSPを使用したオーディオ処理

DSPアーキテクチャ

マルチメディア・ソフトウェア・スタックへのインテグレーション

ヘテロジニアス・マルチコアにおけるオーディオ処理の複雑さを解消

概要オーディオ処理に要求される性能は、上昇の一途をたどっています。以前はメインCPUの余ったサイクルでオーディオ処理を十分に実行できていましたが、最近ではBlu-ray™ディスクの24ビット/192kHz HD（High-Definition）オーディオ・ストリームのデコードや、9.1チャネルのPro Logic® IIzストリームのポストプロセッシングに非常に高い性能が要求されます。そこで考えられるのは、DesignWare ARC AS211SFX/AS221BDオーディオ・プロセッサなど、1つ以上のオーディオ専用DSP（Digital Signal Processor）にCPUの処理をオフロードする方法です。しかしそれではシステム設計が複雑になり、ハードウェアとソフトウェアの両方で多くの課題が発生します。本稿では、まずこれらの課題に言及し、いくつかのアーキテクチャ・ソリューションをご提案します。また、処理のオフロードによって発生する複雑さ以外にも、一般的なLinux®ベース･システムとAndroid™ベース・システムへのオーディオ・ソフトウェアのインテグレーション例を挙げながら、オーディオ処理ソフトウェアを大規模なマルチメディア/製品ソフトウェア・スタックに組み込む方法についてご説明します。

なお、本稿はソフトウェアの面から解説したものですが、ハードウェアとシステムの面を解説したホワイトペーパーも同時に公開しています[1]。併せてお読みいただくと、ハードウェアとソフトウェアの両方で構成されたインテグレーション済みオーディオ・サブシステム・ソリューションの利点をよりよくご理解いただけます。

はじめに

オーディオ処理をメイン・プロセッサからDSPにオフロードするアプローチは、システムに新しいプログラマブル・コアを1つ追加することを意味します。最近はマルチコア・システムに対する理解も深まっていますが、ヘテロジニアス・マルチコア・システム（汎用のメインCPUに、面積と消費電力を最適化したオーディオ処理専用のDSPを追加した構成）向けのソフトウェアを開発するのはまだまだ困難です。

対称型マルチプロセッサ（SMP）システムの場合、システムの複雑さはオペレーティング・システムによってほとんど隠蔽されますが、ヘテロジニアス・マルチプロセッサ・システムの場合は下層のハードウェア・アーキテクチャを意識しながら、その構成に合わせてコードを修正する必要があります。具体的には、ソフトウェアを汎用コアとDSPコアの間で分割し、メイン・コアからDSPを制御できるように修正を加え、圧縮オーディオと非圧縮オーディオのサンプルをDSPとメインCPUの間で交換できるようにしなければなりません。しかし、オーディオ・ドメインの要件に合わせてソフトウェア・インフラストラクチャを最適化すれば、マルチコアの細部を隠蔽でき、オーバーヘッドの増加も防げるため、シングルコアやSMPアーキテクチャと同じくらい簡単に、効率的なヘテロジニアス・マルチコア・システムを実現できます。

ソフトウェア・インフラストラクチャによって、見かけ上オーディオ・ソフトウェアがメインCPU上でローカルに実行されているようにしても、最先端のオーディオ・システム設計で直面する課題がすべて解決するわけではありません。通常、デバイスにはコネクティビティやその他のメディア処理の機能がいくつもあり、オーディオ処理はその1つに過ぎません。したがって、オーディオ・ソフトウェアは全体的なマルチメディアと製品ソフトウェアのスタックにシームレスに統合できなければなりません。この役割を果たすのが、図2に示したアプリケーション・プロセッサ側のオーディオ・プラグイン・コンポーネントです。これは、DSP側のすべてのオーディオ処理のプロキシとして動作します。標準化されたインターフェイスがあればインテグレーションは容易ですが、細分化が進んだコンシューマ・エレクトロニクス市場では、唯一絶対の標準規格は存在しません。

しかも、既存の標準規格やマルチメディア・フレームワークの多くは、処理をDSPにオフロードすることを考慮して開発されていません。クロノス・グループのOpenMAX-IL規格[2]は非常によく知られた業界標準規格ですが、主なターゲットは携帯機器であり、それ以外のコンシューマ・セグメントではあまり採用実績がありません。しかも、この規格の現行バージョンは多くのアプリケーションにとって必要以上に複雑であり、ほとんどの場合（ヘテロジニアス）マルチコア・アーキテクチャ向けに最適化されていません。その他の選択肢として、独自の内製ソリューションも数多く存在しますが、OpenMAXと同様にオープンな選択肢もいくつかあります。

Linuxの世界で最も有名なGStreamer[3]は、完全な機能を備えたクロス・プラットフォームのマルチメディア・フレームワークで、コンシューマ・エレクトロニクス機器での採用が広がっています。Androidの領域では、Google™/Open Handset Alliance™のソリューションの一環として提供されるStagefrightマルチメディア・フレームワーク[4]が勢力を伸ばしています。本稿では、これら3つの一般的なマルチメディア・フレームワークの概要をご説明した後、各フレームワークの長所と短所を簡潔にご説明します。また、面積と消費電力を最適化したDSP（ARC AS211SFX/AS211BDオーディオ・プロセッサなど）に処理のほとんどをオフロードするオーディオ・ソフトウェア・スタックをSoCに組み込み、オーディオ処理性能の向上とシステム消費電力の削減というヘテロジニアス・アーキテクチャの利点を最大限に引き出す方法を、ソフトウェア・エンジニアの負担軽減の観点からご説明します。

ヘテロジニアス・マルチコア・アーキテクチャでソフトウェアによるオーディオ処理の複雑さを隠蔽するには、ホスト・プロセッサ（1つ以上のオーディオ

SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション

DSP をホスティングする汎用 CPU）で提供される API（Application Programming Interface）にいくつかの条件が求められます。

まず1つは、実行場所を意識しなくても良い環境をAPIが提供できることです。APIを使用するクライアント・ソフトウェアは、APIのサービスがCPUで実行されているのかDSPで実行されているのかを気にしなくてよいのが理想です。そうすれば、実際にはDSPで実行されていても、プログラマはそのことを意識せずにシングルコア・アーキテクチャの場合と同じような感覚でAPIを使用できます。つまり、ソフトウェアを通常と同じようにコーディングするだけでホスト・プロセッサの負荷が軽減され、DSPでリアルタイムのオーディオ処理が高速に実行されます。

APIに求められる2つ目の条件は、強力で柔軟であることです。APIは、プログラマに代わって低レベルの制御を行うことにより、使い勝手の良さ、高度な機能性、そして優れた伝達能力を最適なバランスで実現する必要があります。APIを上手に選ぶと、ヘテロジニアス・マルチコア実装の細部をクライアントから隠蔽できます。ただし、ヘテロジニアス・システムでAPIより下層の実装コードを改変する場合は、実装状況を全く意識しない作業というわけにはいきません。たとえば、ホストCPUのコンパイラでなくDSPクロス・コンパイラを使用するなど、ワークフローも異なってきます。したがってAPIは、そのAPIを使用するプログラマが、APIやその仕組みを修正・拡張しなくても目的のユースケースを実現化できるものでなければなりません。幸い、オーディオ処理やマルチメディア処理は、一般的に自然なAPIレベルで実行されます。オーディオ処理は、MP3デコードやサウンドのイコライズなど、オーディオ・データのストリームに対して特定の処理を実行する個々の機能を連結したチェーン（グラフ）によって実行します。APIレベルが一致するとクライアントはこれらの機能をインプリメントするストリーミング・コンポーネントをインスタンス化し、これらを連結することで処理グラフの形成と制御を行います。

APIに求められるもう1つの条件は、効率的な実装方式が可能であることです。オーディオ処理を複数のコアに分散させると、専用の演算リソースが増えて処理が高速化しますが、必然的に通信と同期のオーバーヘッドも生じます。これは、オーディオ・データをホストからDSPへ転送し、DSPで処理したオーディオをホストへ戻す必要があるためで、複数のDSPを使用する場合はDSP間でのオーディオ・サンプルのやりとりも必要になります。また、ホストからDSPへ制御コマンドを送信し、ステータスやイベント情報をホストに返す処理も最小限のレイテンシで行えなければなりません。この結果、デザインにはデータ・コピーとバッファリングを最小限に抑える要件が課せられます。これは、共有メモリーとコア間割り込みという、最小限のハードウェアによるサポートを追加するだけで実現できます。

効率、使い易さ、柔軟性、実行場所を意識しない環境の条件を満たしたソフトウェア・アーキテクチャを図3に示します。図の左側はホスト・プロセッサの、そして右側はDSPのソフトウェア・レイヤとコンポーネントをそれぞれ示しています。DSPのアーキテクチャはすべて共通です。

DSPソフトウェア・スタックは、3つのインフラストラクチャ・コンポーネントと任意の数のオーディオ処理コンポーネントで構成されます。最下層では、リアルタイム・オペレーティング・システムがマルチスレッディングとその他の基本的なOSサービスを提供します。シノプシスのDesignWare SoundWaveオーディオ・サブシステム[5]では、信頼性と効率を考慮してARC MQXを選択しています。次に、マルチメディア・ストリーミング・フレームワーク（MSF）がオーディオ処理コンポーネント用のランタイム環境を提供し、クライアント・ソフトウェアが目的の製品に固有のユースケースをインプリメントしたプレーヤー /レコーダー・アプリケーションを作成するための統一したAPIを提供します。このフレームワークは、すべてのオーディオ処理コンポーネントに必要な共通コードを外に出します。また、コンポーネント間でオーディオ・データ（サンプルまたはフレームを含んだパケット）を通信する機能を提供するとともに、バッファリングの処理、そしてEnd-of-Streamイベントや時間同期といったオーディオ固有の制御機能を提供します。DesignWare SoundWaveオーディオ・サブシステムでは、ARCオーディオ・プロセッサでのオーディオ処理に最適化したARC MSFを使用しています。このMSFはデータ・コピーやホスト・プロセッサの関与なしにコンポーネント間でのデータ・ストリーミングをローカル制御できるようにインプリメントしているため、オーディオ処理モジュールをカスタマ・アプリケーションに容易に組み込めるほか、強力で柔軟なAPIの条件も満たすことができ、効率的なマルチコア実装も実現します。図4は、MP3ファイル再生の処理グラフの生成方法を示したものです。ソース、デコーダ、シンクの各コンポーネントを作成、接続、開始してファイル・システムからMP3を読み出し、コンテンツをデコードし、デコードしたサンプルを出力デバイス・ドライバ経由でスピーカにレンダリングします。

実行場所を意識しない環境の役割を果たすのが、RPC/IPCコンポーネントです。IPC（プロセッサ間通信）コンポーネントが提供するメッセージ・パッシングAPIは物理的なインターコネクト媒体を抽象化します。たとえば共有メモリーを介した通信では、キャッシュ・コヒーレンシを維持するにはデータ・キャッシュをフラッシュして無効にしなければならない場合があります。さらに、IPCコンポーネントは割り込みハンドラやその他の低レベルな細部を処理してくれます。効率を重視して、共有メモリー・バッファ

ARC AS211SFX/AS221BDオーディオ・プロセッサ

図 1. デコードとポストプロセッシングを DSP にオフロードしたオーディオ処理

リーダ（ソースから読み出し）

デマルチプレクサ（コンテナの

フォーマットを解析）

図 2. ホスト・ソフトウェアへの DSP ソフトウェアのインテグレーション

図 3. ヘテロジニアス・マルチコア・オーディオ処理ソリューションのアーキテクチャ

図 4. MSF のソースコード例

ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション

ARC AS211SFX/AS221BDオーディオ・プロセッサ

メディア・プレーヤー・クライアント・アプリケーション

メディア・プレーヤー

リーダ

レンダラ

デコーダラッパ

ポストプロセッシングプラグイン

MSFフレームワーク（リモート・インプリメンテーションへのプロキシ）

ホスト・オペレーティング・システム

アプリケーション・プロセッサ

オーディオ・データ、制御RPC/IPC

MSFフレームワーク

MQX OS

RPC/IPC

デコーダ ポストプロセッシング

デマルチプレクサ デコーダ

次ページに続く

アプリケーション

ビデオ

グラフィックス

オーディオプラグイン

OS

アプリケーションプロセッサ

デコード +

エンコード

ソース +

シンク

ARC AS211SFX/AS221BDオーディオ・プロセッサ

ソフトウェア・インフラストラクチャ ドライバ

ペリフェラルとクロック

ポストプロセッシング

オーディオレンダリング

汎用CPU

オーディオDSP制御API 制御API

オーディオデコード

ポストプロセッシング

オーディオデコード // Step #1 – creating modules

msf_api_source_module_create(“Source”, … ,&source_module_id);msf_api_audio_api_module_create(“MP3 Decoder”, … , &audio_api_module_id);msf_api_sink_module_create(“Sink”, … , &sink_module_id);

// Step #2 – connecting modulesmsf_api_connect_pins(source_module_id, audio_api_module_id, …);msf_api_connect_pins(audio_api_module_id, sink_module_id, …);

// Step #3 – starting data processing by sending START_PLAYBACK messagemsf_api_message_send_to_module(source_module_id,　　　　　　　　　　MSF_MESSAGE_CONTROL_CMD_START_PLAYBACK, …);

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

&A

検証

編S

upport Q&

Aフ

ィジ

カル

編S

upport Q&

A論

理合

成編

New

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

ン

1918 次ページに続く

Technology Update ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション前ページより続く

図 6. Android におけるマルチメディア再生

ホスト・アーキテクチャ

GStreamer

Stagefright

OpenMAX-IL

マルチメディア・フレームワークとAPI

へのポインタを返す「ゼロ・コピー」メッセージ・パッシング関数を使用すれば、送信側のクライアントはデータのコピーを防ぐことができます。クライアントは、送信データで共有メモリー・バッファを直接フィルし、完了したらIPCコンポーネントに通知します。

RPC（リモート・プロシージャ・コール）コンポーネントはIPCをさらに拡張したもので、IPCだけでは対処できない要求を満たします。メッセージ・パッシングは通信媒体の細部を隠蔽しますが、一般にソフトウェア・モジュールの通信向けプログラミング・パラダイムとしては自然ではありません。その場合にはCまたはC++の関数呼び出しを使用します。RPCコンポーネントは、関数呼び出しのパラダイムをシングルコアからマルチコアに拡張するためのインフラストラクチャを提供します。関数を呼び出すと、その関数のインプリメンテーションを実行するのではなく、対応するプロキシ関数が呼び出され、このプロキシ関数が関数のすべての引数を1つのメッセージにシリアライズし、もう一方のコアのスタブ関数に渡します。このスタブ関数は引数をデシリアライズし、実際の実行環境を呼び出し、関数の実行結果を最初のコアの関数呼び出し元へ返します。DesignWare SoundWaveオーディオ・サブシステムで使用しているRPCソリューションにはインターフェイス定義言語からプロキシ関数とスタブ関数を自動で生成する機能があり、オブジェクトのライフサイクル・マネジメントやポインタなど多くの引数タイプのマーシャリングをサポートしています。リモート関数の呼び出しは完全に透過的に行われ、ローカル関数を呼び出すのと同じくらい簡単に行えます。

最後に、もう1つの重要な要素としてオーディオ処理コンポーネントがあります。メディア・ストリーミング・フレームワーク上に構築されたオーディオ処理コンポーネントは、オーディオ処理アルゴリズムを実装します。一般に、設計者は最初から特定のホストCPUやDSPに合わせてアルゴリズムを作成するのではなく、まず通常のCコードでアルゴリズムを記述します。最近のコンパイラは、このソースコードをもとに特定のプロセッサに合わせて高度に最適化した実装を行えます。

DSPコアに関しては、エンジニアがソースコードをさらに最適化してDSPのアーキテクチャを最大限に有効利用することも可能です。これには、DSP固有の命令（intrinsic）を使用したり、キャッシュやその他のローカル・メモリーの利用を最適化する方法があります。しかしDSPのコードを最適化して最大限の性能を引き出す作業は非常に高い専門性が要求されます。このため、必要なオーディオ・コーデックやポストプロセッシング・アルゴリズムはDSPサプライヤから提供されるのが理想的です。

多くの製品では、ソフトウェア・スタックはDSPよりもホスト・プロセッサ側の方がはるかに複雑です。ホスト・プロセッサは、オーディオ以外にもビデオ、（インターネット）通信、ストレージ、グラフィックス、ユーザー・インターフェイス、各種アプリケーション・ソフトウェアなどの機能を実行しなければなりません。図3（P17参照）の左上は、オーディオ機能に焦点を当てた一般的なマルチメディア・プレーヤーのアーキテクチャを示したものです。メディア・プレーヤー・クライアント・アプリケーションはGUIとアプリケーション・ロジックを提供し、この中にはプレイリスト管理やさらに高度なコンテンツ管理と再生/停止/一時停止/シーク・コントロールが含まれます。その下のメディア・プレーヤー・コンポーネントは、実際のオーディオ再生機能やアプリケーションのその他のユースケース

（録音など）をインプリメントします。このコンポーネントは、一連の処理コンポーネントを連結したチェーンを作成します。処理の内容としては、まずソース（SDカードに保存されたファイルやインターネット・ラジオ局からのストリーミング・オーディオなど）から圧縮オーディオを読み出し、次にオーディオ・フレームが含まれているコンテナ・フォーマットを解析してオーディオ・フレームをアンパックします（オーディオ/ビデオ・ストリームのデマルチプレクスを実行）。次に、圧縮されたオーディオ・フレームをメディア・プレーヤー・コンポーネントがデコードし、さらにオプションとしてオーディオ品質を補正したりチャネル数を調整するなどのポストプロセッシングを実行します。このチェーンの最後のコンポーネントは、DACを経由してRawオーディオ・サンプルをスピーカにレンダリングするか、またはHDMI™などのデジタルI/Oペリフェラルを経由して別のデバイスやストレージに転送します。

図3（P17参照）の左下は、ホスト・プロセッサのインフラストラクチャ・コンポーネントを示しています。ここでは、Linux、Windows®、iOSなど汎用オペレーティング・システムの組み込み版がよく使用されます。（リモート化された）MSFコンポーネントは、DSP側のRPC/IPCコンポーネントと対になるホスト側のRPC/IPCコンポーネントを使用します。ホスト側のMSFコンポーネントは、リモートDSPのインプリメンテーションをホスト・プロセッサで利用可能にするプロキシ関数のみで構成されます。MSFフレームワーク関数、DSP側で実行するように割り当てられた個々のオーディオの処理モジュールに対する制御関数が用意されています。

残りのコンポーネント、すなわちデコーダ・ラッパとポストプロセッシング・プラグインは、MSFレイヤによって提供されるインターフェイスを、

オーディオ処理モジュールが実装されるメディア・プレーヤーで必要なインターフェイスに変換します。以下、本稿ではこれらのコンポーネントについて詳しくご説明します。まず3つの業界標準マルチメディア・フレームワークをご紹介した後で、DSPベースのオーディオ処理をこれらのフレームワークに効率よく組み込むインテグレーション方法についてご説明します。

「はじめに」で申し上げたように、細分化が進んだコンシューマ家電市場で は、唯 一 絶 対 の マ ル チ メ デ ィ ア 規 格 は 存 在 し ま せ ん。こ こ で は、GStreamer、Stagefright、OpenMAX-ILという3つのフレームワークを取り上げ、それぞれを比較してみます。

GStreamerはオープンソースのマルチメディア・ソフトウェア・ソリューションで、独自のコーデックやメディア・プレーヤーを統合できるなど、商用利用にも有利なLGPLv2ライセンスで提供されています。このフレームワークは完全な機能を備えており、個々の処理エレメントを組み合わせて任意のメディア処理グラフを作成できます。コア・フレームワーク以外にも、GStreamerにはすべての必要なオーディオとビデオ・フォーマットの処理エレメントを提供するプラグインが豊富に用意されています。GStreamerは、入力ソース・ファイルまたはフォーマットと必要な出力シンクを指定するだけで完全なストリーミング・グラフを自動で作成できるツールも提供しています。これらのツールは入力フォーマットを出力フォーマットに変換する際に必要となる中間コンポーネントをすべて自動で検出し、これらのコンポーネントを処理チェーンに挿入してくれます。メディア・プレーヤーやその他のアプリケーション・ソフトウェアはGStreamerソリューションには含まれませんが、サードパーティから多くのプレーヤーが提供されています。グラフの自動作成機能があるため、アプリケーションからファイルを再生する場合もいくつかの関数を呼び出すか、またはコマンドラインから「gst-launch playbin uri=file:」コマンドを実行するだけで簡単に再生できます。

StagefrightはAndroidの標準メディア・プレーヤーです。図6に示すように、Androidのマルチメディア・スタックは前述した例によく似ています。最上位には、メディア・プレーヤー・アプリとフレームワークで構成されるアプリケーション・スタックがあります。アプリはAndroid標準のメディア・プレーヤー・アプリケーションで、フレームワークはネイティブなメディア・プレーヤー・サービスへのJava™バインディングです。実際のメディア・プレーヤー・インプリメンテーションはこのサービスに含まれます。Androidアーキテクチャは複数のプレーヤーのインプリメンテーションを

サポートしており、メディアの種類やその他のポリシーに基づいて専用のプレーヤーが呼び出されます。標準のプレーヤーはStagefrightですが、機器メーカーが別のより高機能なプレーヤーやメーカー固有のハードウェアに最適化したプレーヤーをサービスにプラグイン形式で追加することもできます。ここで追加するプレーヤーは、メーカー独自またはレガシーのソリューションでも、あるいはオープンソースのGStreamerプレーヤーでもかまいません。ある携帯電話のSoCメーカーがGStreamerプレーヤーをAndroidに移植し[6]、現在はGStreamerコミュニティがこれを継承してサポートを行っています[7]。 Stagefrightは、商用利用にも有利なAndroid標準のApache 2.0ソフトウェア・ライセンスで提供されています。このフレームワークは、OpenCoreプレーヤーの置き換えとして数年前にGoogleによってAndroid専用に開発されたもので、モバイル環境で一般的なほとんどのオーディオやビデオ・フォーマットの再生をサポートしています（ただしBlu-Ray HDオーディオ・コ ー デ ッ ク と マ ル チ チ ャ ネ ル 出 力 は サ ポ ー ト し て い ま せ ん）。Stagefrightは新しいオーディオ処理エレメントを使って拡張が可能ですが、GStreamerほど柔軟性は高くありません。Stagefrightプレーヤーのメディア処理グラフは、ソース、デマルチプレクサ（コンテナの解析）、デコード・コンポーネントで固定されているため、任意のグラフの作成はできません。オーディオのミキシングとレンダリングはプレーヤー外部のAudioFlingerコンポーネントによって処理されます。このコンポーネントはオプションとしてプラグイン機能によるポストプロセッシングもサポートしています。Stagefrightには数多くの一般的なコーデックのソースコードが含まれていますが、多くの場合、メーカーはこれを差し替えるか拡張して独自のコーデック、特別に最適化したコーデック、あるいはハードウェア・アクセラレーションによるコーデックを使用するのが一般的です。これ ら の 追 加 コ ン ポ ー ネ ン ト はStagefrightコ ー デ ッ クAPIま た はOpenMAX-ILインターフェイスのどちらも実装できます。

本 稿 で 取 り 上 げ る3つ 目 の マ ル チ メ デ ィ ア・フ レ ー ム ワ ー ク がOpenMAX-ILです。これは単一の実装方式をベースにしたフレームワークではなく、API規格で、業界コンソーシアムのクロノス・グループによって定義が行われています（クロノス・グループはこのほかにもOpenGL®

などのオープンで移植性を備えたいくつかのクロス・プラットフォーム規格を定義しています）。OpenMAX-IL（Integration Layer）は、それぞれ異なるソフトウェア・レイヤをターゲットとした3つのAPI規格の2番目に当たるものです。プレーヤー・レベルのインターフェイスを提供するのがOpenMAX-AL（Application Layer）で、DCT変換などの演算カーネルを備えた低レベル・レイヤがOpenMAX-DL（Development Layer）ですが、これらはいずれも本稿の内容には直接関係しないので説明を割愛します。

GStreamerプラグインGStreamerに含まれる150以上のプラグイン

図 5. GStreamer マルチメディア・フレームワーク

GStreamerツール マルチメディア・アプリケーション

gst-inspectgst-launchgst-editor

メディアプレーヤー

VoIPとビデオ会議

ストリーミングサーバ

ビデオエディタ (...)

GStreamerコア・フレームワークパイプライン・アーキテクチャ

メディア非依存ベース・クラスメッセージ・バスメディア・タイプ・ネゴシエーションプラグイン・システムユーティリティ・ライブラリ言語バインディング

プロトコル- file:- http:- rtsp:- ...

ソース- alsa- v4l2- tcp/upd- ...

フォーマット- avi- mp4- ogg- ...

コーデック- mp3- mpeg4- vorbis- ...

シンク- alsa- xvideo- tcp/udp- ...

フィルタ- converters- mixers- effects- ...

(...)

サードパーティ製プラグイン

オーディオ・レンダリング（->AudioFlinger）

JAVA メディア・プレーヤーアプリケーション

メディア・プレーヤーアプリケーションフレームワーク

Linuxユーザー空間

メディア・プレーヤーサービス

AudioFlinger

その他のオーディオドライバ

Alsaカーネルドライバ

Linuxカーネル空間

メディア・プレーヤー・サービス

Stagefrightプレーヤー

GStreamerプレーヤー

OpenCoreプレーヤー

MIDIプレーヤー

Vorbisプレーヤー

リーダ（ソースから読み出し）

デマルチプレクサ（コンテナの

フォーマットを解析）

ビデオデコード

ビデオ・レンダリング（->SurfaceFlinger）

オーディオデコード

…

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

&A

検証

編S

upport Q&

Aフ

ィジ

カル

編S

upport Q&

A論

理合

成編

New

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

ン

1918 次ページに続く

Technology Update ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション前ページより続く

図 6. Android におけるマルチメディア再生

ホスト・アーキテクチャ

GStreamer

Stagefright

OpenMAX-IL

マルチメディア・フレームワークとAPI

へのポインタを返す「ゼロ・コピー」メッセージ・パッシング関数を使用すれば、送信側のクライアントはデータのコピーを防ぐことができます。クライアントは、送信データで共有メモリー・バッファを直接フィルし、完了したらIPCコンポーネントに通知します。

RPC（リモート・プロシージャ・コール）コンポーネントはIPCをさらに拡張したもので、IPCだけでは対処できない要求を満たします。メッセージ・パッシングは通信媒体の細部を隠蔽しますが、一般にソフトウェア・モジュールの通信向けプログラミング・パラダイムとしては自然ではありません。その場合にはCまたはC++の関数呼び出しを使用します。RPCコンポーネントは、関数呼び出しのパラダイムをシングルコアからマルチコアに拡張するためのインフラストラクチャを提供します。関数を呼び出すと、その関数のインプリメンテーションを実行するのではなく、対応するプロキシ関数が呼び出され、このプロキシ関数が関数のすべての引数を1つのメッセージにシリアライズし、もう一方のコアのスタブ関数に渡します。このスタブ関数は引数をデシリアライズし、実際の実行環境を呼び出し、関数の実行結果を最初のコアの関数呼び出し元へ返します。DesignWare SoundWaveオーディオ・サブシステムで使用しているRPCソリューションにはインターフェイス定義言語からプロキシ関数とスタブ関数を自動で生成する機能があり、オブジェクトのライフサイクル・マネジメントやポインタなど多くの引数タイプのマーシャリングをサポートしています。リモート関数の呼び出しは完全に透過的に行われ、ローカル関数を呼び出すのと同じくらい簡単に行えます。

最後に、もう1つの重要な要素としてオーディオ処理コンポーネントがあります。メディア・ストリーミング・フレームワーク上に構築されたオーディオ処理コンポーネントは、オーディオ処理アルゴリズムを実装します。一般に、設計者は最初から特定のホストCPUやDSPに合わせてアルゴリズムを作成するのではなく、まず通常のCコードでアルゴリズムを記述します。最近のコンパイラは、このソースコードをもとに特定のプロセッサに合わせて高度に最適化した実装を行えます。

DSPコアに関しては、エンジニアがソースコードをさらに最適化してDSPのアーキテクチャを最大限に有効利用することも可能です。これには、DSP固有の命令（intrinsic）を使用したり、キャッシュやその他のローカル・メモリーの利用を最適化する方法があります。しかしDSPのコードを最適化して最大限の性能を引き出す作業は非常に高い専門性が要求されます。このため、必要なオーディオ・コーデックやポストプロセッシング・アルゴリズムはDSPサプライヤから提供されるのが理想的です。

多くの製品では、ソフトウェア・スタックはDSPよりもホスト・プロセッサ側の方がはるかに複雑です。ホスト・プロセッサは、オーディオ以外にもビデオ、（インターネット）通信、ストレージ、グラフィックス、ユーザー・インターフェイス、各種アプリケーション・ソフトウェアなどの機能を実行しなければなりません。図3（P17参照）の左上は、オーディオ機能に焦点を当てた一般的なマルチメディア・プレーヤーのアーキテクチャを示したものです。メディア・プレーヤー・クライアント・アプリケーションはGUIとアプリケーション・ロジックを提供し、この中にはプレイリスト管理やさらに高度なコンテンツ管理と再生/停止/一時停止/シーク・コントロールが含まれます。その下のメディア・プレーヤー・コンポーネントは、実際のオーディオ再生機能やアプリケーションのその他のユースケース

（録音など）をインプリメントします。このコンポーネントは、一連の処理コンポーネントを連結したチェーンを作成します。処理の内容としては、まずソース（SDカードに保存されたファイルやインターネット・ラジオ局からのストリーミング・オーディオなど）から圧縮オーディオを読み出し、次にオーディオ・フレームが含まれているコンテナ・フォーマットを解析してオーディオ・フレームをアンパックします（オーディオ/ビデオ・ストリームのデマルチプレクスを実行）。次に、圧縮されたオーディオ・フレームをメディア・プレーヤー・コンポーネントがデコードし、さらにオプションとしてオーディオ品質を補正したりチャネル数を調整するなどのポストプロセッシングを実行します。このチェーンの最後のコンポーネントは、DACを経由してRawオーディオ・サンプルをスピーカにレンダリングするか、またはHDMI™などのデジタルI/Oペリフェラルを経由して別のデバイスやストレージに転送します。

図3（P17参照）の左下は、ホスト・プロセッサのインフラストラクチャ・コンポーネントを示しています。ここでは、Linux、Windows®、iOSなど汎用オペレーティング・システムの組み込み版がよく使用されます。（リモート化された）MSFコンポーネントは、DSP側のRPC/IPCコンポーネントと対になるホスト側のRPC/IPCコンポーネントを使用します。ホスト側のMSFコンポーネントは、リモートDSPのインプリメンテーションをホスト・プロセッサで利用可能にするプロキシ関数のみで構成されます。MSFフレームワーク関数、DSP側で実行するように割り当てられた個々のオーディオの処理モジュールに対する制御関数が用意されています。

残りのコンポーネント、すなわちデコーダ・ラッパとポストプロセッシング・プラグインは、MSFレイヤによって提供されるインターフェイスを、

オーディオ処理モジュールが実装されるメディア・プレーヤーで必要なインターフェイスに変換します。以下、本稿ではこれらのコンポーネントについて詳しくご説明します。まず3つの業界標準マルチメディア・フレームワークをご紹介した後で、DSPベースのオーディオ処理をこれらのフレームワークに効率よく組み込むインテグレーション方法についてご説明します。

「はじめに」で申し上げたように、細分化が進んだコンシューマ家電市場で は、唯 一 絶 対 の マ ル チ メ デ ィ ア 規 格 は 存 在 し ま せ ん。こ こ で は、GStreamer、Stagefright、OpenMAX-ILという3つのフレームワークを取り上げ、それぞれを比較してみます。

GStreamerはオープンソースのマルチメディア・ソフトウェア・ソリューションで、独自のコーデックやメディア・プレーヤーを統合できるなど、商用利用にも有利なLGPLv2ライセンスで提供されています。このフレームワークは完全な機能を備えており、個々の処理エレメントを組み合わせて任意のメディア処理グラフを作成できます。コア・フレームワーク以外にも、GStreamerにはすべての必要なオーディオとビデオ・フォーマットの処理エレメントを提供するプラグインが豊富に用意されています。GStreamerは、入力ソース・ファイルまたはフォーマットと必要な出力シンクを指定するだけで完全なストリーミング・グラフを自動で作成できるツールも提供しています。これらのツールは入力フォーマットを出力フォーマットに変換する際に必要となる中間コンポーネントをすべて自動で検出し、これらのコンポーネントを処理チェーンに挿入してくれます。メディア・プレーヤーやその他のアプリケーション・ソフトウェアはGStreamerソリューションには含まれませんが、サードパーティから多くのプレーヤーが提供されています。グラフの自動作成機能があるため、アプリケーションからファイルを再生する場合もいくつかの関数を呼び出すか、またはコマンドラインから「gst-launch playbin uri=file:」コマンドを実行するだけで簡単に再生できます。

StagefrightはAndroidの標準メディア・プレーヤーです。図6に示すように、Androidのマルチメディア・スタックは前述した例によく似ています。最上位には、メディア・プレーヤー・アプリとフレームワークで構成されるアプリケーション・スタックがあります。アプリはAndroid標準のメディア・プレーヤー・アプリケーションで、フレームワークはネイティブなメディア・プレーヤー・サービスへのJava™バインディングです。実際のメディア・プレーヤー・インプリメンテーションはこのサービスに含まれます。Androidアーキテクチャは複数のプレーヤーのインプリメンテーションを

サポートしており、メディアの種類やその他のポリシーに基づいて専用のプレーヤーが呼び出されます。標準のプレーヤーはStagefrightですが、機器メーカーが別のより高機能なプレーヤーやメーカー固有のハードウェアに最適化したプレーヤーをサービスにプラグイン形式で追加することもできます。ここで追加するプレーヤーは、メーカー独自またはレガシーのソリューションでも、あるいはオープンソースのGStreamerプレーヤーでもかまいません。ある携帯電話のSoCメーカーがGStreamerプレーヤーをAndroidに移植し[6]、現在はGStreamerコミュニティがこれを継承してサポートを行っています[7]。 Stagefrightは、商用利用にも有利なAndroid標準のApache 2.0ソフトウェア・ライセンスで提供されています。このフレームワークは、OpenCoreプレーヤーの置き換えとして数年前にGoogleによってAndroid専用に開発されたもので、モバイル環境で一般的なほとんどのオーディオやビデオ・フォーマットの再生をサポートしています（ただしBlu-Ray HDオーディオ・コ ー デ ッ ク と マ ル チ チ ャ ネ ル 出 力 は サ ポ ー ト し て い ま せ ん）。Stagefrightは新しいオーディオ処理エレメントを使って拡張が可能ですが、GStreamerほど柔軟性は高くありません。Stagefrightプレーヤーのメディア処理グラフは、ソース、デマルチプレクサ（コンテナの解析）、デコード・コンポーネントで固定されているため、任意のグラフの作成はできません。オーディオのミキシングとレンダリングはプレーヤー外部のAudioFlingerコンポーネントによって処理されます。このコンポーネントはオプションとしてプラグイン機能によるポストプロセッシングもサポートしています。Stagefrightには数多くの一般的なコーデックのソースコードが含まれていますが、多くの場合、メーカーはこれを差し替えるか拡張して独自のコーデック、特別に最適化したコーデック、あるいはハードウェア・アクセラレーションによるコーデックを使用するのが一般的です。これ ら の 追 加 コ ン ポ ー ネ ン ト はStagefrightコ ー デ ッ クAPIま た はOpenMAX-ILインターフェイスのどちらも実装できます。

本 稿 で 取 り 上 げ る3つ 目 の マ ル チ メ デ ィ ア・フ レ ー ム ワ ー ク がOpenMAX-ILです。これは単一の実装方式をベースにしたフレームワークではなく、API規格で、業界コンソーシアムのクロノス・グループによって定義が行われています（クロノス・グループはこのほかにもOpenGL®

などのオープンで移植性を備えたいくつかのクロス・プラットフォーム規格を定義しています）。OpenMAX-IL（Integration Layer）は、それぞれ異なるソフトウェア・レイヤをターゲットとした3つのAPI規格の2番目に当たるものです。プレーヤー・レベルのインターフェイスを提供するのがOpenMAX-AL（Application Layer）で、DCT変換などの演算カーネルを備えた低レベル・レイヤがOpenMAX-DL（Development Layer）ですが、これらはいずれも本稿の内容には直接関係しないので説明を割愛します。

GStreamerプラグインGStreamerに含まれる150以上のプラグイン

図 5. GStreamer マルチメディア・フレームワーク

GStreamerツール マルチメディア・アプリケーション

gst-inspectgst-launchgst-editor

メディアプレーヤー

VoIPとビデオ会議

ストリーミングサーバ

ビデオエディタ (...)

GStreamerコア・フレームワークパイプライン・アーキテクチャ

メディア非依存ベース・クラスメッセージ・バスメディア・タイプ・ネゴシエーションプラグイン・システムユーティリティ・ライブラリ言語バインディング

プロトコル- file:- http:- rtsp:- ...

ソース- alsa- v4l2- tcp/upd- ...

フォーマット- avi- mp4- ogg- ...

コーデック- mp3- mpeg4- vorbis- ...

シンク- alsa- xvideo- tcp/udp- ...

フィルタ- converters- mixers- effects- ...

(...)

サードパーティ製プラグイン

オーディオ・レンダリング（->AudioFlinger）

JAVA メディア・プレーヤーアプリケーション

メディア・プレーヤーアプリケーションフレームワーク

Linuxユーザー空間

メディア・プレーヤーサービス

AudioFlinger

その他のオーディオドライバ

Alsaカーネルドライバ

Linuxカーネル空間

メディア・プレーヤー・サービス

Stagefrightプレーヤー

GStreamerプレーヤー

OpenCoreプレーヤー

MIDIプレーヤー

Vorbisプレーヤー

リーダ（ソースから読み出し）

デマルチプレクサ（コンテナの

フォーマットを解析）

ビデオデコード

ビデオ・レンダリング（->SurfaceFlinger）

オーディオデコード

…

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

&A

検証

編S

upport Q&

Aフ

ィジ

カル

編S

upport Q&

A論

理合

成編

New

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

ン

2120

Technology Update ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション前ページより続く

各フレームワークの比較SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション

図7は、OpenMAX-ILフレームワークのアーキテクチャです。プレーヤーのデータフロー・グラフが固定されておらず、個々の処理エレメントを組み合わせて任意のグラフを作成できるという点で、OpenMAX-ILはGStreamerと共通しています。エレメント間のメディア・データ交換のインターフェイスとプロトコル以外にも、OpenMAX-ILはメディア・フォーマット、入力/出力ポート、そしてMP3デコーダやオーディオ・ミキサなど特定のエレメント用のコマンドも標準化しています。 OpenMAX-ILは、メディア処理実装方式に左右されない標準のクロス・プラットフォーム・インターフェイスとなることを目標に設計されています。アルゴリズムをハードウェアとソフトウェアのどちらに実装しても、ローカルCPUとリモートのどちらに実装しても、常に同じインターフェイスを提供します。非トンネル、トンネル、ディープ・トンネルという3種類のコンポーネント間通信により、効率的で移植性の高い実装が可能です。非トンネル通信は、クライアントがユースケースに合わせてインスタンス化したフレームワーク・コンポーネントにより、クライアント・アプリケーションを通じてデータを転送します。このプロトコルは移植性が最も高い反面、多くのデータ・コピーが発生するため効率は最も悪くなります。トンネル通信は、データ（へのポインタ）を実装コンポーネント間で直接通信すると、データ・コピーとクライアント・アプリケーションの関与をなくしています。図7には、2種類のトンネル通信が示されています。1つはOpenMAX-IL規格によって完全に定義された、インターオペラビリティのあるトンネル通信で、もう1つはプラットフォームを実装する際にターゲット・ハードウェアに合わせて最適な定義を行えるプラットフォーム固有のトンネル通信です。後者はディープ・トンネル通信とも呼ばれ、通常はこのプロトコルが最も効率は良くなります。ただし、標準規格に基づいていないため、インターオペラビリティはありません。

個々の製品でどのマルチメディア・フレームワークを使用するかは、表1に示したいくつかの要因を考慮して決める必要があります。プログラマの立場から重視すべき点は、クロス・フレームワークのサポートとDSPオフロードの2つです。GStreamerとStagefrightはどちらもOpenMAX-ILコンポーネントをクロス・フレームワークで使用できます。ただしOpenMAXはそれ自体が完全なマルチメディア・フレームワークであるため、これらのフレームワークをスタックすると機能の重複、複雑さの増大、オーバーヘッドの増加といった問題が生じます。あるSoCメーカーの報告によると、GStreamer OpenMAXラッパ・ベースのソリューションの代わりにGStreamerエレメントを使ってネイティブなコーデック・インターフェイスを直接使用したところ、性能が30%向上したといいます。一般に、OpenMAX規格は他のメディア処理フレームワークと組み合わせて使うには複雑すぎると設計者の間では考えられています。Stagefright OpenMAXソリューションはディープ・トンネル通信をサポートしていないため、なるべく多くのデータをヘテロジニアス・マルチコア・ソリューションによっ

てローカルのDSP上に保持し、消費電力を最小限に抑えて最大限の性能を発揮するといった用途には適していません。

次に考慮しなくてはならないのは、フレームワークがオーディオ処理のDSPへのオフロードをサポートしているかどうかという点です。ここに挙げた3つのソリューションは、いずれも標準ではヘテロジニアス・マルチコア・ハードウェア・アーキテクチャをサポートしておらず、インターオペラビリティがあるOpenMAX-ILのトンネル通信もサポートしていません。しかしこれらのフレームワークはいずれもオーディオ処理モジュールを特定のプラットフォームに合わせて最適化した実装方式をサポートしており、ディープ・トンネル通信にも対応します。次のセクションで詳しくご紹介しますが、コーデックのオフロードとディープ・トンネル通信はGStreamerとOpenMAXとで高い親和性があります。Stagefrightの場合は処理チェーンが固定されており、ポストプロセッシングとレンダリングをプレーヤー外部の独立したAudioFlingerコンポーネントで実行しているため、GStreamerやOpenMAXより多くの修正が必要になります。

このセクションでは、DSPベースのオーディオ・サブシステムをより大規模なSoCに組み込むソフトウェア・インテグレーションの方法ついて詳しくご説明します。ここでの説明では、先にご説明した全体的なヘテロジニアス・マルチメディア・ソフトウェア・アーキテクチャとホストCPUマルチメディア・フレームワークの使用を前提とします。まず、効率を考慮してデータをローカルに保持するため、アナログ/デジタル・オーディオの入出力を含めすべてのオーディオ処理をサブシステムに実装します。サブシステムは、1つ以上のDSP（ARC AS211SFX/AS221BDオーディオ・プロセッサなど）、オーディオI/Oペリフェラル、そしてDSP処理とホスト・ソフトウェア・インターフェイス用のソフトウェア・コンポーネント一式で構成されます。図8は、2つのDSPを使用したシステムのコンポーネントのデータフロー・グラフの概念図を示したものです。

ホスト・ソフトウェア・スタックから見ると、システムはシングルコア・システムと何ら変わりません。コンポーネントは、マルチメディア・

フレームワークの通常の呼び出しによってインスタンス化、接続、制御されます。ただし、ホスト側のいくつかのコンポーネントは、DSP側で動作するコンポーネントの単なるプロキシに過ぎません。これを図8では破線で示しています（「G」と書かれたコンポーネント）。ディープ・トンネルで実装された仮想データフロー接続も破線で示しています。コンポーネントがホスト側でインスタンス化されると、このコンポーネントは（RPC/IPCインフラストラクチャを利用して）DSP側に対応するコンポーネントを作成します（図8で「M」と書かれたコンポーネント）。DSP MSFは同じDSPで実行するように割り当てられているコンポーネント間の接続はすべてローカルにインプリメントするため、システムはデータ・ストリーミング時のコア間通信を最小限に抑えられます。コア間の通信が必要な場合、ホスト側のコンポーネントはオーディオ処理コンポーネントだけでなく、トンネルの実装に必要なプロセッサ間データ・バッファ、ソース、シンク・コンポーネントも作成します。これはホスト・コンポーネントの内部実装の一部であるため、ホスト・プロセッサ側のコンポーネントを使用しているクライアント・アプリケーションからは完全に意識される必要がありません。

ホスト・プロセッサ側でどのマルチメディア・フレームワークを使用するかによって、ホスト・コンポーネントの必要な実装方式が決まります。GStreamerとStagefrightで同じOpenMAX-ILベースのコンポーネントを使用することもできますが、複雑になるだけで性能も低下するため推奨できません。しかも、OpenMAX-ILが標準化しているのはモバイル分野のオーディオ・コンポーネントの一部にすぎません。

プログラマは、RPC/IPCとDSP MSFインフラストラクチャ、DSPに最適化したオーディオ処理モジュールを利用して、個々のフレームワークに最適化したホスト・コンポーネントを比較的シンプルに実装できます。GStreamerの場合は、前述のようにMSF関数を直接呼び出し、（ディープ）トンネル通信を形成するエレメントを使ってプラグイン・モジュールを実装するのが最適なソリューションです。同様に、OpenMAX-ILの場合はMSFを使って独自のディープ・トンネル・プロトコルを実装したコンポーネントが最適です。Androidの場合、最適なソリューションはアプリケーション分野によって異なります。オーディオ処理の要件がそれほど厳しくないモバイル・アプリケーションの場合は、標準のStagefrightとシンプル

図 7. OpenMAX-IL フレームワークのアーキテクチャ

表 1. 各フレームワークの比較 ARCコア#1

図 8. ヘテロジニアス・マルチコア SoC におけるオーディオ・データフロー・グラフの概念図

図 9. GStreamer オーディオ・エレメントのディープ・トンネル通信のソースコード例

[1] Wolf, P., van der (2012). Audio Subsystems for Efficient SoC Integration; Integrating High-Definition Multi-Channel Audio Solutions at the Speed of Sound. White Paper, Synopsys, Inc.[2] The Khronos™ group (2008). OpenMAX™ Integration Layer Application Programming Interface Specification. http://www.khronos.org/registry/omxil/specs/OpenMAX_IL_1_1_2_Specification.pdf[3] GStreamerオープンソース・マルチメディア・フレームワーク。プロジェクト公式ウェブサイト http://gstreamer.freedesktop.org[4] Stagefrightマルチメディア・フレームワーク。Android開発者向けウェブサイト http://developer.android.com[5] DesignWare SoundWaveオーディオ・サブシステム。シノプシスのIPウェブサイト http://www.synopsys.com/dw/ipdir.php?ds=audio_subsystem[6] Gaignard, B. (2010). Android and GStreamer. Conference presentation, Embedded Linux Conference Europe, October 2010, Cambridge. http://elinux.org/images/a/a4/Android_and_Gstreamer.ppt, St-Ericsson Inc.[7] GStreamer Androidインストール・ガイド http://gstreamer.freedesktop.org/wiki/GstreamerAndroid_InstallInstructions.

で基本的なOpenMAX-ILコンポーネントを組み合わせるだけで十分で、トンネル通信も必要ありません。

ホーム・オーディオ/ビデオ・アプリケーションなど、HD/マルチチャネル・オーディオや複雑な処理グラフを使用するような要求の厳しいアプリケーションでは、Stagefrightの代わりにAndroid GStreamerプレーヤーを使用することをお奨めします。事実、Google TV™デバイスやスマートフォンなど、多くの機器がこのような構成を採用しています。

図9は、適切に選択したDSPマルチメディア・ストリーミングAPIを特定のホスト・マルチメディア・フレームワークで必要なAPIにシンプルかつ効率よく変換する方法をご紹介するため、DesignWare SoundWaveオーディオ・サブシステムに含まれるGStreamerプラグインのソースコード・フラグメントを示したものです。このフラグメントは、2つのメディア処理エレメントを連結するGStreamerの「ピン接続」関数をインプリメントしています。この関数は、接続のタイプに応じて追加のシンク・コンポーネントを作成し、ピンを接続して（ディープ）トンネルを形成します。通常はオーディオ処理をインプリメントするGStreamerの「チェーン」または

「ループ」関数の実装もシンプルです。これはディープ・トンネルの場合には無効になり、ホストCPUに割り当てられた部分とDSPに割り当てられた部分の境界に位置するコンポーネントの場合はデータをコア間通信バッファに送信します。

まとめ市場をリードするハイエンド・オーディオ製品を投入するには、正しいソフトウェア・ソリューション選びが欠かせません。処理性能と開発の手間の両方の意味で効率的なハイエンド・オーディオ製品を開発するには、数多くのソフトウェアを使用する必要があります。本稿でご説明したように、オーディオ処理をARC AS211SFX/AS221BDオーディオ・プロセッサなどのDSPにオフロードした場合でも、最適なマルチメディア・ソフトウェア・アーキテクチャを使用すれば、システム・インテグレータやアプリケーション・プログラマはソフトウェアの複雑性を意識しなくて済みます。リアルタイムOS、マルチメディア・ストリーミング・フレームワーク、最適化済みオーディオ・コーデックや処理関数のライブラリ、プロセッサ間通信（IPC）、そして一般的に使用されるマルチメディアAPIのインターフェイス・レイヤを統合したソリューションを使えば、システム・インテグレータやアプリケーション開発者からハイエンド・オーディオの複雑さを隠蔽できます。オーディオ・サブシステムをSoCに組み込むソフトウェア・インテグレーションも簡単な作業で容易に行え、現在から将来にわたってオーディオ領域の課題に対処できます。

GStreamer Stagefright OpenMAX-IL

APIの標準化 ×（ただしOMXコンポーネントを使用可） ○

○ ○グラフの柔軟性 ×ヘテロジニアス

マルチコアのサポート×

（ただし専用のインプリメンテーションで可能）

アプリケーション領域 すべて モバイル モバイル

参考文献

ホストCPU

ドライバARC - ARC間

ストリーミング

ホスト- ARC間ストリーミング

ローカルストリーミング

ソース

FIFO

シンク

FIFO

ARC AS221BDオーディオ・プロセッサにインスタンス化したデータフロー・グラフ

ARCコア#0

ソース

ILクライアント

マルチメディア・フレームワーク

フレームワークコンポーネント

フレームワークコンポーネント

フレームワークコンポーネント

フレームワークコンポーネント

フレームワークコンポーネント

トンネル通信

トンネル通信

ソースコンポーネント

非トンネル通信

アクセラレータコンポーネント

IPC IPC

ハードウェアアクセラレーション

コーデック

OpenM

AXコ

ア

ホストコンポーネント

connect_msf_outpin (GstPad* pad){ GstAudioModule *filter = …; // this elements private data

if (!pad_is_deeptunnel(pad)) { /* create sink module for connection to CPU->DSP fifo */ msf_api_sink_module_create(filter->msf_coreid, "Sink module", filter->output_fifo_buffer, ... , &sink_module_id); msf_api_connect_pins(filter->msf_moduleid, sink_module_id, ...); } else if (pad_is_corecrossing(pad)) { /* create sink module for connection to DSP->DSP fifo */ msf_api_sink_module_create(filter->msf_coreid, "Sink module", filter->msf_sharedfifo, ... , &sink_module_id); msf_api_connect_pins(filter->msf_moduleid, sink_module_id, ...); } else { /* deep-tunnel AND no core-crossing */ /* get the module id of the peer MSF module */ g_object_get(G_OBJECT(peerelement),"msf_moduleid",&peer_module_id,…); msf_api_connect_pins(filter->msf_moduleid, peer_module_id, ...); }}

Technology Update

最新

技術

情報

Technology Update

最新

技術

情報

Support Q

&A

検証

編S

upport Q&

Aフ

ィジ

カル

編S

upport Q&

A論

理合

成編

New

s Release

ニュ

ース

リリ

ース

オー

トモ

ーテ

ィブ

ソリ

ュー

ショ

ン

2120

Technology Update ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション前ページより続く

各フレームワークの比較SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション

図7は、OpenMAX-ILフレームワークのアーキテクチャです。プレーヤーのデータフロー・グラフが固定されておらず、個々の処理エレメントを組み合わせて任意のグラフを作成できるという点で、OpenMAX-ILはGStreamerと共通しています。エレメント間のメディア・データ交換のインターフェイスとプロトコル以外にも、OpenMAX-ILはメディア・フォーマット、入力/出力ポート、そしてMP3デコーダやオーディオ・ミキサなど特定のエレメント用のコマンドも標準化しています。 OpenMAX-ILは、メディア処理実装方式に左右されない標準のクロス・プラットフォーム・インターフェイスとなることを目標に設計されています。アルゴリズムをハードウェアとソフトウェアのどちらに実装しても、ローカルCPUとリモートのどちらに実装しても、常に同じインターフェイスを提供します。非トンネル、トンネル、ディープ・トンネルという3種類のコンポーネント間通信により、効率的で移植性の高い実装が可能です。非トンネル通信は、クライアントがユースケースに合わせてインスタンス化したフレームワーク・コンポーネントにより、クライアント・アプリケーションを通じてデータを転送します。このプロトコルは移植性が最も高い反面、多くのデータ・コピーが発生するため効率は最も悪くなります。トンネル通信は、データ（へのポインタ）を実装コンポーネント間で直接通信すると、データ・コピーとクライアント・アプリケーションの関与をなくしています。図7には、2種類のトンネル通信が示されています。1つはOpenMAX-IL規格によって完全に定義された、インターオペラビリティのあるトンネル通信で、もう1つはプラットフォームを実装する際にターゲット・ハードウェアに合わせて最適な定義を行えるプラットフォーム固有のトンネル通信です。後者はディープ・トンネル通信とも呼ばれ、通常はこのプロトコルが最も効率は良くなります。ただし、標準規格に基づいていないため、インターオペラビリティはありません。

個々の製品でどのマルチメディア・フレームワークを使用するかは、表1に示したいくつかの要因を考慮して決める必要があります。プログラマの立場から重視すべき点は、クロス・フレームワークのサポートとDSPオフロードの2つです。GStreamerとStagefrightはどちらもOpenMAX-ILコンポーネントをクロス・フレームワークで使用できます。ただしOpenMAXはそれ自体が完全なマルチメディア・フレームワークであるため、これらのフレームワークをスタックすると機能の重複、複雑さの増大、オーバーヘッドの増加といった問題が生じます。あるSoCメーカーの報告によると、GStreamer OpenMAXラッパ・ベースのソリューションの代わりにGStreamerエレメントを使ってネイティブな