Technology Update
最新技術情報
メディア・プレーヤー・クライアント・アプリケーション
メインCPUの余ったサイクルでオーディオ処理を十分に実行できていました
ソフトウェア・インフラストラクチャによって、見かけ上オーディオ・ソ
が、最近ではBlu-ray™ディスクの24ビット/192kHz HD（High-Definition）
フトウェアがメイン CPU 上でローカルに実行されているようにしても、最
オーディオ・ストリームのデコードや、9.1チャネルのPro Logic® IIzストリー
先端のオーディオ・システム設計で直面する課題がすべて解決するわけで
ムのポストプロセッシングに非常に高い性能が要求されます。そこで考えら
はありません。通常、デバイスにはコネクティビティやその他のメディア
MSFフレームワーク
（リモート・インプリメンテーションへのプロキシ）
RPC/
IPC
オーディオ・データ、制御
ホスト・オペレーティング・システム
MQX OS
アプリケーション・プロセッサ
ARC AS211SFX/AS221BDオーディオ・プロセッサ
れるのは、DesignWare ARC AS211SFX/AS221BDオーディオ・プロセッサ
処理の機能がいくつもあり、オーディオ処理はその 1 つに過ぎません。し
など、1つ以上のオーディオ専用DSP（Digital Signal Processor）に CPU の処
たがって、オーディオ・ソフトウェアは全体的なマルチメディアと製品ソ
理をオフロードする方法です。しかしそれではシステム設計が複雑になり、
フトウェアのスタックにシームレスに統合できなければなりません。この
ハードウェアとソフトウェアの両方で多くの課題が発生します。本稿では、
役割を果たすのが、図 2 に示したアプリケーション・プロセッサ側のオー
まずこれらの課題に言及し、いくつかのアーキテクチャ・ソリューション
ディオ・プラグイン・コンポーネントです。これは、DSP側のすべてのオー
をご提案します。また、処理のオフロードによって発生する複雑さ以外に
ディオ処理のプロキシとして動作します。標準化されたインターフェイス
DSP を ホ ス テ ィ ン グ す る 汎 用 CPU）で 提 供 さ れ る API（Application
も、一般的な Linux® ベース･システムと Android™ベース・システムへの
があればインテグレーションは容易ですが、細分化が進んだコンシューマ・
Programming Interface）にいくつかの条件が求められます。
オーディオ・ソフトウェアのインテグレーション例を挙げながら、オーディ
エレクトロニクス市場では、唯一絶対の標準規格は存在しません。
クに組み込む方法についてご説明します。
アプリケーション
せてお読みいただくと、ハードウェアとソフトウェアの両方で構成された
デコード
+
エンコード
ソース
+
シンク
ポスト
プロセッシング
トリーミング・フレームワーク（MSF）がオーディオ処理コンポーネント用
にコーディングするだけでホスト・プロセッサの負荷が軽減され、DSP で
のランタイム環境を提供し、クライアント・ソフトウェアが目的の製品に
リアルタイムのオーディオ処理が高速に実行されます。
固有のユースケースをインプリメントしたプレーヤー / レコーダー・アプ
リケーションを作成するための統一した API を提供します。このフレーム
はじめに
DSPを使用したオーディオ処理
図 2. ホスト・ソフトウェアへの DSP ソフトウェアのインテグレーション
オーディオ処理をメイン・プロセッサから DSP にオフロードするアプロー
ワークは、すべてのオーディオ処理コンポーネントに必要な共通コードを
ログラマに代わって低レベルの制御を行うことにより、使い勝手の良さ、高
外に出します。また、コンポーネント間でオーディオ・データ（サンプルま
度な機能性、そして優れた伝達能力を最適なバランスで実現する必要があ
たはフレームを含んだパケット）を通信する機能を提供するとともに、バッ
ります。API を上手に選ぶと、ヘテロジニアス・マルチコア実装の細部を
ファリングの処理、そして End-of-Stream イベントや時間同期といった
クライアントから隠蔽できます。ただし、ヘテロジニアス・システムで
オーディオ固有の制御機能を提供します。DesignWare SoundWave オー
チは、システムに新しいプログラマブル・コアを 1 つ追加することを意味
しかも、既存の標準規格やマルチメディア・フレームワークの多くは、処理
API より下層の実装コードを改変する場合は、実装状況を全く意識しない
ディオ・サブシステムでは、ARC オーディオ・プロセッサでのオーディオ
します。最近はマルチコア・システムに対する理解も深まっていますが、
を DSP にオフロードすることを考慮して開発されていません。クロノス・
作業というわけにはいきません。たとえば、ホスト CPU のコンパイラでな
処理に最適化したARC MSFを使用しています。このMSFはデータ・コピー
ヘテロジニアス・マルチコア・システム（汎用のメイン CPU に、面積と消
グループの OpenMAX-IL 規格 [2] は非常によく知られた業界標準規格です
く DSP クロス・コンパイラを使用するなど、ワークフローも異なってきま
やホスト・プロセッサの関与なしにコンポーネント間でのデータ・ストリー
費電力を最適化したオーディオ処理専用の DSP を追加した構成）向けのソ
が、主なターゲットは携帯機器であり、それ以外のコンシューマ・セグメン
す。したがって API は、その API を使用するプログラマが、API やその仕組
ミングをローカル制御できるようにインプリメントしているため、オー
フトウェアを開発するのはまだまだ困難です。
トではあまり採用実績がありません。しかも、この規格の現行バージョン
みを修正・拡張しなくても目的のユースケースを実現化できるものでなけ
ディオ処理モジュールをカスタマ・アプリケーションに容易に組み込める
は多くのアプリケーションにとって必要以上に複雑であり、ほとんどの場
ればなりません。幸い、オーディオ処理やマルチメディア処理は、一般的に
ほか、強力で柔軟な API の条件も満たすことができ、効率的なマルチコア実
合（ヘテロジニアス）マルチコア・アーキテクチャ向けに最適化されていま
自然な API レベルで実行されます。オーディオ処理は、MP3 デコードやサ
装も実現します。図 4 は、MP3 ファイル再生の処理グラフの生成方法を示
せん。その他の選択肢として、独自の内製ソリューションも数多く存在し
ウンドのイコライズなど、オーディオ・データのストリームに対して特定
したものです。ソース、デコーダ、シンクの各コンポーネントを作成、接続、
ますが、OpenMAX と同様にオープンな選択肢もいくつかあります。
の処理を実行する個々の機能を連結したチェーン（グラフ）によって実行し
開始してファイル・システムから MP3 を読み出し、コンテンツをデコード
ます。API レベルが一致するとクライアントはこれらの機能をインプリメ
し、デコードしたサンプルを出力デバイス・ドライバ経由でスピーカにレ
Linux の世界で最も有名な GStreamer[3]は、完全な機能を備えたクロス・
ントするストリーミング・コンポーネントをインスタンス化し、これらを
ンダリングします。
プラットフォームのマルチメディア・フレームワークで、コンシューマ・
連結することで処理グラフの形成と制御を行います。
リーダ
（ソースから読み出し）
デマルチプレクサ
（コンテナの
フォーマットを解析）
オーディオ
デコード
オーディオ
レンダリング
汎用CPU
オーディオDSP
制御API
オーディオ
デコード
制御API
ポスト
プロセッシング
ARC AS211SFX/AS221BDオーディオ・プロセッサ
エレクトロニクス機器での採用が広がっています。Android の領域では、
Google™/Open Handset Alliance™のソリューションの一環として提供さ
API に求められるもう 1 つの条件は、効率的な実装方式が可能であることで
// 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);
れるStagefright マルチメディア・フレームワーク[4]が勢力を伸ばしてい
す。オーディオ処理を複数のコアに分散させると、専用の演算リソースが
ます。本稿では、これら3つの一般的なマルチメディア・フレームワークの
増えて処理が高速化しますが、必然的に通信と同期のオーバーヘッドも生
概要をご説明した後、各フレームワークの長所と短所を簡潔にご説明します。
じます。これは、オーディオ・データをホストから DSP へ転送し、DSP で
対称型マルチプロセッサ（SMP）システムの場合、システムの複雑さはオペ
また、面積と消費電力を最適化したDSP（ARC AS211SFX/AS211BD オー
処理したオーディオをホストへ戻す必要があるためで、複数の DSP を使用
レーティング・システムによってほとんど隠蔽されますが、ヘテロジニア
ディオ・プロセッサなど）に処理のほとんどをオフロードするオーディオ・
する場合はDSP間でのオーディオ・サンプルのやりとりも必要になります。
ス・マルチプロセッサ・システムの場合は下層のハードウェア・アーキテ
ソフトウェア・スタックを SoC に組み込み、オーディオ処理性能の向上と
また、ホストから DSP へ制御コマンドを送信し、ステータスやイベント情
クチャを意識しながら、その構成に合わせてコードを修正する必要があり
システム消費電力の削減というヘテロジニアス・アーキテクチャの利点を
報をホストに返す処理も最小限のレイテンシで行えなければなりません。
ます。具体的には、ソフトウェアを汎用コアと DSP コアの間で分割し、メ
最大限に引き出す方法を、ソフトウェア・エンジニアの負担軽減の観点か
この結果、デザインにはデータ・コピーとバッファリングを最小限に抑え
イン・コアから DSP を制御できるように修正を加え、圧縮オーディオと非
らご説明します。
る要件が課せられます。これは、共有メモリーとコア間割り込みという、最
実行場所を意識しない環境の役割を果たすのが、RPC/IPC コンポーネント
小限のハードウェアによるサポートを追加するだけで実現できます。
です。IPC（プロセッサ間通信）コンポーネントが提供するメッセージ・パッ
図 1. デコードとポストプロセッシングを DSP にオフロードしたオーディオ処理
圧縮オーディオのサンプルを DSP とメイン CPU の間で交換できるようにし
// Step #2 – connecting modules
msf_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 message
msf_api_message_send_to_module(source_module_id,
MSF_MESSAGE_CONTROL_CMD_START_PLAYBACK, …);
図 4. MSF のソースコード例
隠蔽でき、オーバーヘッドの増加も防げるため、シングルコアや SMP アー
ヘテロジニアス・マルチコアにおける
オーディオ処理の複雑さを解消
キテクチャと同じくらい簡単に、効率的なヘテロジニアス・マルチコア・
ヘテロジニアス・マルチコア・アーキテクチャでソフトウェアによるオーディ
サの、そして右側は DSP のソフトウェア・レイヤとコンポーネントをそれ
ります。さらに、IPC コンポーネントは割り込みハンドラやその他の低レ
システムを実現できます。
オ処理の複雑さを隠蔽するには、ホスト・プロセッサ（1 つ以上のオーディオ
ぞれ示しています。DSP のアーキテクチャはすべて共通です。
ベルな細部を処理してくれます。効率を重視して、共有メモリー・バッファ
なければなりません。しかし、オーディオ・ドメインの要件に合わせてソ
フトウェア・インフラストラクチャを最適化すれば、マルチコアの細部を
16
API に求められる 2 つ目の条件は、強力で柔軟であることです。API は、プ
検証編
ペリフェラル
とクロック
効率を考慮して ARC MQX を選択しています。次に、マルチメディア・ス
うな感覚で API を使用できます。つまり、ソフトウェアを通常と同じよう
Support Q&A
ARC AS211SFX/AS221BD
オーディオ・プロセッサ
DesignWare SoundWave オーディオ・サブシステム [5] では、信頼性と
マはそのことを意識せずにシングルコア・アーキテクチャの場合と同じよ
フィジカル編
アプリケーション
プロセッサ
ン グ と そ の 他 の 基 本 的 な OS サ ー ビ ス を 提 供 し ま す。シ ノ プ シ ス の
のが理想です。そうすれば、実際には DSP で実行されていても、プログラ
Support Q&A
ドライバ
層では、リアルタイム・オペレーティング・システムがマルチスレッディ
CPU で実行されているのか DSP で実行されているのかを気にしなくてよい
論理合成編
ソフトウェア・インフラストラクチャ
ネントと任意の数のオーディオ処理コンポーネントで構成されます。最下
です。API を使用するクライアント・ソフトウェアは、API のサービスが
Support Q&A
OS
DSP ソフトウェア・スタックは、3 つのインフラストラクチャ・コンポー
まず 1 つは、実行場所を意識しなくても良い環境を API が提供できること
最新技術情報
点をよりよくご理解いただけます。
オーディオ
プラグイン
DSPアーキテクチャ
Technology Update
インテグレーション済みオーディオ・サブシステム・ソリューションの利
グラフィックス
ステムの面を解説したホワイトペーパーも同時に公開しています [1]。併
ビデオ
なお、本稿はソフトウェアの面から解説したものですが、ハードウェアとシ
図 3. ヘテロジニアス・マルチコア・オーディオ処理ソリューションのアーキテクチャ
オートモーティブ
ソリューション
オ処理ソフトウェアを大規模なマルチメディア / 製品ソフトウェア・スタッ
MSFフレームワーク
RPC/
IPC
最新技術情報
オーディオ処理に要求される性能は、上昇の一途をたどっています。以前は
Technology Update
マルチメディア・ソフトウェア・スタックへの
インテグレーション
ポスト
プロセッシング
デコーダ
ポストプロセッシング
プラグイン
News Release
概要
デコーダ
ラッパ
デコーダ
レンダラ
リーダ
SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション
デマルチ
プレクサ
ニュースリリース
ハイエンド・オーディオ機能を手軽に実現する
ソフトウェア・ソリューション
メディア・プレーヤー
シング API は物理的なインターコネクト媒体を抽象化します。たとえば共
効率、使い易さ、柔軟性、実行場所を意識しない環境の条件を満たしたソフ
有メモリーを介した通信では、キャッシュ・コヒーレンシを維持するには
トウェア・アーキテクチャを図3に示します。図の左側はホスト・プロセッ
データ・キャッシュをフラッシュして無効にしなければならない場合があ
次ページに続く
17
Technology Update
最新技術情報
メディア・プレーヤー・クライアント・アプリケーション
メインCPUの余ったサイクルでオーディオ処理を十分に実行できていました
ソフトウェア・インフラストラクチャによって、見かけ上オーディオ・ソ
が、最近ではBlu-ray™ディスクの24ビット/192kHz HD（High-Definition）
フトウェアがメイン CPU 上でローカルに実行されているようにしても、最
オーディオ・ストリームのデコードや、9.1チャネルのPro Logic® IIzストリー
先端のオーディオ・システム設計で直面する課題がすべて解決するわけで
ムのポストプロセッシングに非常に高い性能が要求されます。そこで考えら
はありません。通常、デバイスにはコネクティビティやその他のメディア
MSFフレームワーク
（リモート・インプリメンテーションへのプロキシ）
RPC/
IPC
オーディオ・データ、制御
ホスト・オペレーティング・システム
MQX OS
アプリケーション・プロセッサ
ARC AS211SFX/AS221BDオーディオ・プロセッサ
れるのは、DesignWare ARC AS211SFX/AS221BDオーディオ・プロセッサ
処理の機能がいくつもあり、オーディオ処理はその 1 つに過ぎません。し
など、1つ以上のオーディオ専用DSP（Digital Signal Processor）に CPU の処
たがって、オーディオ・ソフトウェアは全体的なマルチメディアと製品ソ
理をオフロードする方法です。しかしそれではシステム設計が複雑になり、
フトウェアのスタックにシームレスに統合できなければなりません。この
ハードウェアとソフトウェアの両方で多くの課題が発生します。本稿では、
役割を果たすのが、図 2 に示したアプリケーション・プロセッサ側のオー
まずこれらの課題に言及し、いくつかのアーキテクチャ・ソリューション
ディオ・プラグイン・コンポーネントです。これは、DSP側のすべてのオー
をご提案します。また、処理のオフロードによって発生する複雑さ以外に
ディオ処理のプロキシとして動作します。標準化されたインターフェイス
DSP を ホ ス テ ィ ン グ す る 汎 用 CPU）で 提 供 さ れ る API（Application
も、一般的な Linux® ベース･システムと Android™ベース・システムへの
があればインテグレーションは容易ですが、細分化が進んだコンシューマ・
Programming Interface）にいくつかの条件が求められます。
オーディオ・ソフトウェアのインテグレーション例を挙げながら、オーディ
エレクトロニクス市場では、唯一絶対の標準規格は存在しません。
クに組み込む方法についてご説明します。
アプリケーション
せてお読みいただくと、ハードウェアとソフトウェアの両方で構成された
デコード
+
エンコード
ソース
+
シンク
ポスト
プロセッシング
トリーミング・フレームワーク（MSF）がオーディオ処理コンポーネント用
にコーディングするだけでホスト・プロセッサの負荷が軽減され、DSP で
のランタイム環境を提供し、クライアント・ソフトウェアが目的の製品に
リアルタイムのオーディオ処理が高速に実行されます。
固有のユースケースをインプリメントしたプレーヤー / レコーダー・アプ
リケーションを作成するための統一した API を提供します。このフレーム
はじめに
DSPを使用したオーディオ処理
図 2. ホスト・ソフトウェアへの DSP ソフトウェアのインテグレーション
オーディオ処理をメイン・プロセッサから DSP にオフロードするアプロー
ワークは、すべてのオーディオ処理コンポーネントに必要な共通コードを
ログラマに代わって低レベルの制御を行うことにより、使い勝手の良さ、高
外に出します。また、コンポーネント間でオーディオ・データ（サンプルま
度な機能性、そして優れた伝達能力を最適なバランスで実現する必要があ
たはフレームを含んだパケット）を通信する機能を提供するとともに、バッ
ります。API を上手に選ぶと、ヘテロジニアス・マルチコア実装の細部を
ファリングの処理、そして End-of-Stream イベントや時間同期といった
クライアントから隠蔽できます。ただし、ヘテロジニアス・システムで
オーディオ固有の制御機能を提供します。DesignWare SoundWave オー
チは、システムに新しいプログラマブル・コアを 1 つ追加することを意味
しかも、既存の標準規格やマルチメディア・フレームワークの多くは、処理
API より下層の実装コードを改変する場合は、実装状況を全く意識しない
ディオ・サブシステムでは、ARC オーディオ・プロセッサでのオーディオ
します。最近はマルチコア・システムに対する理解も深まっていますが、
を DSP にオフロードすることを考慮して開発されていません。クロノス・
作業というわけにはいきません。たとえば、ホスト CPU のコンパイラでな
処理に最適化したARC MSFを使用しています。このMSFはデータ・コピー
ヘテロジニアス・マルチコア・システム（汎用のメイン CPU に、面積と消
グループの OpenMAX-IL 規格 [2] は非常によく知られた業界標準規格です
く DSP クロス・コンパイラを使用するなど、ワークフローも異なってきま
やホスト・プロセッサの関与なしにコンポーネント間でのデータ・ストリー
費電力を最適化したオーディオ処理専用の DSP を追加した構成）向けのソ
が、主なターゲットは携帯機器であり、それ以外のコンシューマ・セグメン
す。したがって API は、その API を使用するプログラマが、API やその仕組
ミングをローカル制御できるようにインプリメントしているため、オー
フトウェアを開発するのはまだまだ困難です。
トではあまり採用実績がありません。しかも、この規格の現行バージョン
みを修正・拡張しなくても目的のユースケースを実現化できるものでなけ
ディオ処理モジュールをカスタマ・アプリケーションに容易に組み込める
は多くのアプリケーションにとって必要以上に複雑であり、ほとんどの場
ればなりません。幸い、オーディオ処理やマルチメディア処理は、一般的に
ほか、強力で柔軟な API の条件も満たすことができ、効率的なマルチコア実
合（ヘテロジニアス）マルチコア・アーキテクチャ向けに最適化されていま
自然な API レベルで実行されます。オーディオ処理は、MP3 デコードやサ
装も実現します。図 4 は、MP3 ファイル再生の処理グラフの生成方法を示
せん。その他の選択肢として、独自の内製ソリューションも数多く存在し
ウンドのイコライズなど、オーディオ・データのストリームに対して特定
したものです。ソース、デコーダ、シンクの各コンポーネントを作成、接続、
ますが、OpenMAX と同様にオープンな選択肢もいくつかあります。
の処理を実行する個々の機能を連結したチェーン（グラフ）によって実行し
開始してファイル・システムから MP3 を読み出し、コンテンツをデコード
ます。API レベルが一致するとクライアントはこれらの機能をインプリメ
し、デコードしたサンプルを出力デバイス・ドライバ経由でスピーカにレ
Linux の世界で最も有名な GStreamer[3]は、完全な機能を備えたクロス・
ントするストリーミング・コンポーネントをインスタンス化し、これらを
ンダリングします。
プラットフォームのマルチメディア・フレームワークで、コンシューマ・
連結することで処理グラフの形成と制御を行います。
リーダ
（ソースから読み出し）
デマルチプレクサ
（コンテナの
フォーマットを解析）
オーディオ
デコード
オーディオ
レンダリング
汎用CPU
オーディオDSP
制御API
オーディオ
デコード
制御API
ポスト
プロセッシング
ARC AS211SFX/AS221BDオーディオ・プロセッサ
エレクトロニクス機器での採用が広がっています。Android の領域では、
Google™/Open Handset Alliance™のソリューションの一環として提供さ
API に求められるもう 1 つの条件は、効率的な実装方式が可能であることで
// 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);
れるStagefright マルチメディア・フレームワーク[4]が勢力を伸ばしてい
す。オーディオ処理を複数のコアに分散させると、専用の演算リソースが
ます。本稿では、これら3つの一般的なマルチメディア・フレームワークの
増えて処理が高速化しますが、必然的に通信と同期のオーバーヘッドも生
概要をご説明した後、各フレームワークの長所と短所を簡潔にご説明します。
じます。これは、オーディオ・データをホストから DSP へ転送し、DSP で
対称型マルチプロセッサ（SMP）システムの場合、システムの複雑さはオペ
また、面積と消費電力を最適化したDSP（ARC AS211SFX/AS211BD オー
処理したオーディオをホストへ戻す必要があるためで、複数の DSP を使用
レーティング・システムによってほとんど隠蔽されますが、ヘテロジニア
ディオ・プロセッサなど）に処理のほとんどをオフロードするオーディオ・
する場合はDSP間でのオーディオ・サンプルのやりとりも必要になります。
ス・マルチプロセッサ・システムの場合は下層のハードウェア・アーキテ
ソフトウェア・スタックを SoC に組み込み、オーディオ処理性能の向上と
また、ホストから DSP へ制御コマンドを送信し、ステータスやイベント情
クチャを意識しながら、その構成に合わせてコードを修正する必要があり
システム消費電力の削減というヘテロジニアス・アーキテクチャの利点を
報をホストに返す処理も最小限のレイテンシで行えなければなりません。
ます。具体的には、ソフトウェアを汎用コアと DSP コアの間で分割し、メ
最大限に引き出す方法を、ソフトウェア・エンジニアの負担軽減の観点か
この結果、デザインにはデータ・コピーとバッファリングを最小限に抑え
イン・コアから DSP を制御できるように修正を加え、圧縮オーディオと非
らご説明します。
る要件が課せられます。これは、共有メモリーとコア間割り込みという、最
実行場所を意識しない環境の役割を果たすのが、RPC/IPC コンポーネント
小限のハードウェアによるサポートを追加するだけで実現できます。
です。IPC（プロセッサ間通信）コンポーネントが提供するメッセージ・パッ
図 1. デコードとポストプロセッシングを DSP にオフロードしたオーディオ処理
圧縮オーディオのサンプルを DSP とメイン CPU の間で交換できるようにし
// Step #2 – connecting modules
msf_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 message
msf_api_message_send_to_module(source_module_id,
MSF_MESSAGE_CONTROL_CMD_START_PLAYBACK, …);
図 4. MSF のソースコード例
隠蔽でき、オーバーヘッドの増加も防げるため、シングルコアや SMP アー
ヘテロジニアス・マルチコアにおける
オーディオ処理の複雑さを解消
キテクチャと同じくらい簡単に、効率的なヘテロジニアス・マルチコア・
ヘテロジニアス・マルチコア・アーキテクチャでソフトウェアによるオーディ
サの、そして右側は DSP のソフトウェア・レイヤとコンポーネントをそれ
ります。さらに、IPC コンポーネントは割り込みハンドラやその他の低レ
システムを実現できます。
オ処理の複雑さを隠蔽するには、ホスト・プロセッサ（1 つ以上のオーディオ
ぞれ示しています。DSP のアーキテクチャはすべて共通です。
ベルな細部を処理してくれます。効率を重視して、共有メモリー・バッファ
なければなりません。しかし、オーディオ・ドメインの要件に合わせてソ
フトウェア・インフラストラクチャを最適化すれば、マルチコアの細部を
16
API に求められる 2 つ目の条件は、強力で柔軟であることです。API は、プ
検証編
ペリフェラル
とクロック
効率を考慮して ARC MQX を選択しています。次に、マルチメディア・ス
うな感覚で API を使用できます。つまり、ソフトウェアを通常と同じよう
Support Q&A
ARC AS211SFX/AS221BD
オーディオ・プロセッサ
DesignWare SoundWave オーディオ・サブシステム [5] では、信頼性と
マはそのことを意識せずにシングルコア・アーキテクチャの場合と同じよ
フィジカル編
アプリケーション
プロセッサ
ン グ と そ の 他 の 基 本 的 な OS サ ー ビ ス を 提 供 し ま す。シ ノ プ シ ス の
のが理想です。そうすれば、実際には DSP で実行されていても、プログラ
Support Q&A
ドライバ
層では、リアルタイム・オペレーティング・システムがマルチスレッディ
CPU で実行されているのか DSP で実行されているのかを気にしなくてよい
論理合成編
ソフトウェア・インフラストラクチャ
ネントと任意の数のオーディオ処理コンポーネントで構成されます。最下
です。API を使用するクライアント・ソフトウェアは、API のサービスが
Support Q&A
OS
DSP ソフトウェア・スタックは、3 つのインフラストラクチャ・コンポー
まず 1 つは、実行場所を意識しなくても良い環境を API が提供できること
最新技術情報
点をよりよくご理解いただけます。
オーディオ
プラグイン
DSPアーキテクチャ
Technology Update
インテグレーション済みオーディオ・サブシステム・ソリューションの利
グラフィックス
ステムの面を解説したホワイトペーパーも同時に公開しています [1]。併
ビデオ
なお、本稿はソフトウェアの面から解説したものですが、ハードウェアとシ
図 3. ヘテロジニアス・マルチコア・オーディオ処理ソリューションのアーキテクチャ
オートモーティブ
ソリューション
オ処理ソフトウェアを大規模なマルチメディア / 製品ソフトウェア・スタッ
MSFフレームワーク
RPC/
IPC
最新技術情報
オーディオ処理に要求される性能は、上昇の一途をたどっています。以前は
Technology Update
マルチメディア・ソフトウェア・スタックへの
インテグレーション
ポスト
プロセッシング
デコーダ
ポストプロセッシング
プラグイン
News Release
概要
デコーダ
ラッパ
デコーダ
レンダラ
リーダ
SoCへのオーディオ・サブシステムのソフトウェア・インテグレーション
デマルチ
プレクサ
ニュースリリース
ハイエンド・オーディオ機能を手軽に実現する
ソフトウェア・ソリューション
メディア・プレーヤー
シング API は物理的なインターコネクト媒体を抽象化します。たとえば共
効率、使い易さ、柔軟性、実行場所を意識しない環境の条件を満たしたソフ
有メモリーを介した通信では、キャッシュ・コヒーレンシを維持するには
トウェア・アーキテクチャを図3に示します。図の左側はホスト・プロセッ
データ・キャッシュをフラッシュして無効にしなければならない場合があ
次ページに続く
17
Technology Update
ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション
前ページより続く
したら IPC コンポーネントに通知します。
サ側の方がはるかに複雑です。ホスト・プロセッサは、オーディオ以外に
もビデオ、
（インターネット）通信、ストレージ、グラフィックス、ユーザー・
RPC（リモート・プロシージャ・コール）コンポーネントは IPC をさらに拡
インターフェイス、各種アプリケーション・ソフトウェアなどの機能を実
張したもので、IPC だけでは対処できない要求を満たします。メッセージ・
行しなければなりません。図 3（P17 参照）の左上は、オーディオ機能に焦
パッシングは通信媒体の細部を隠蔽しますが、一般にソフトウェア・モ
点を当てた一般的なマルチメディア・プレーヤーのアーキテクチャを示し
ジュールの通信向けプログラミング・パラダイムとしては自然ではありま
たものです。メディア・プレーヤー・クライアント・アプリケーションは
せん。その場合には C または C++ の関数呼び出しを使用します。RPC コン
GUI とアプリケーション・ロジックを提供し、この中にはプレイリスト管
ポーネントは、関数呼び出しのパラダイムをシングルコアからマルチコア
理やさらに高度なコンテンツ管理と再生 / 停止 / 一時停止 / シーク・コント
に拡張するためのインフラストラクチャを提供します。関数を呼び出すと、
ロールが含まれます。その下のメディア・プレーヤー・コンポーネントは、
その関数のインプリメンテーションを実行するのではなく、対応するプロ
実際のオーディオ再生機能やアプリケーションのその他のユースケース
キシ関数が呼び出され、このプロキシ関数が関数のすべての引数を 1 つの
（録音など）をインプリメントします。このコンポーネントは、一連の処理
コンポーネントを連結したチェーンを作成します。処理の内容としては、
このスタブ関数は引数をデシリアライズし、実際の実行環境を呼び出し、関
まずソース（SD カードに保存されたファイルやインターネット・ラジオ局
数の実行結果を最初のコアの関数呼び出し元へ返します。DesignWare
からのストリーミング・オーディオなど）から圧縮オーディオを読み出し、
SoundWave オーディオ・サブシステムで使用している RPC ソリューショ
次にオーディオ・フレームが含まれているコンテナ・フォーマットを解析
ンにはインターフェイス定義言語からプロキシ関数とスタブ関数を自動で
してオーディオ・フレームをアンパックします（オーディオ / ビデオ・スト
生成する機能があり、オブジェクトのライフサイクル・マネジメントやポ
リームのデマルチプレクスを実行）。次に、圧縮されたオーディオ・フレー
インタなど多くの引数タイプのマーシャリングをサポートしています。リ
ムをメディア・プレーヤー・コンポーネントがデコードし、さらにオプショ
モート関数の呼び出しは完全に透過的に行われ、ローカル関数を呼び出す
ンとしてオーディオ品質を補正したりチャネル数を調整するなどのポスト
のと同じくらい簡単に行えます。
プロセッシングを実行します。このチェーンの最後のコンポーネントは、
DAC を経由して Raw オーディオ・サンプルをスピーカにレンダリングす
Linuxユーザー空間
メディア・プレーヤー・サービス
…
メディア・プレーヤー
サービス
AudioFlinger
その他のオーディオ
ドライバ
Linuxカーネル空間
Stagefright
プレーヤー
GStreamer
プレーヤー
OpenCore
プレーヤー
MIDI
プレーヤー
Alsaカーネル
ドライバ
リーダ
（ソースから読み出し）
プレーヤーが呼び出されます。標準のプレーヤーは Stagefright ですが、機
て詳しくご説明します。まず 3 つの業界標準マルチメディア・フレームワー
器メーカーが別のより高機能なプレーヤーやメーカー固有のハードウェア
クをご紹介した後で、DSP ベースのオーディオ処理をこれらのフレームワー
に最適化したプレーヤーをサービスにプラグイン形式で追加することもで
きます。ここで追加するプレーヤーは、メーカー独自またはレガシーのソ
イスやストレージに転送します。
一般に、設計者は最初から特定のホスト CPU や DSP に合わせてアルゴリズ
図 3（P17 参照）の左下は、ホスト・プロセッサのインフラストラクチャ・
ムを作成するのではなく、まず通常の C コードでアルゴリズムを記述しま
コンポーネントを示しています。ここでは、Linux、Windows®、iOS など
マルチメディア・フレームワークとAPI
す。最近のコンパイラは、このソースコードをもとに特定のプロセッサに
汎用オペレーティング・システムの組み込み版がよく使用されます。
（リ
合わせて高度に最適化した実装を行えます。
モート化された）MSF コンポーネントは、DSP 側の RPC/IPC コンポーネン
リューションでも、あるいはオープンソースの GStreamer プレーヤーでも
ディオ処理コンポーネントは、オーディオ処理アルゴリズムを実装します。
化して最大限の性能を引き出す作業は非常に高い専門性が要求されます。
このため、必要なオーディオ・コーデックやポストプロセッシング・アル
残りのコンポーネント、すなわちデコーダ・ラッパとポストプロセッシン
ゴリズムは DSP サプライヤから提供されるのが理想的です。
グ・プラグインは、MSF レイヤによって提供されるインターフェイスを、
マルチメディア・アプリケーション
GStreamerコア・フレームワーク
パイプライン・アーキテクチャ
ビデオ
エディタ
(...)
メディア非依存
ベース・クラス
メッセージ・バス
メディア・タイプ・ネゴシエーション
プラグイン・システム
ユーティリティ・ライブラリ
言語バインディング
GStreamer
ソース
- alsa
- v4l2
- tcp/upd
- ...
フォーマット
- avi
- mp4
- ogg
- ...
コーデック
- mp3
- mpeg4
- vorbis
- ...
フィルタ
- converters
- mixers
- effects
- ...
GStreamerプラグイン
GStreamerに含まれる150以上のプラグイン
図 5. GStreamer マルチメディア・フレームワーク
18
シンク
- alsa
- xvideo
- tcp/udp
- ...
(...)
サードパーティ製
プラグイン
フォーマットの再生をサポートしています（ただし Blu-Ray HD オーディ
オ・コ ー デ ッ ク と マ ル チ チ ャ ネ ル 出 力 は サ ポ ー ト し て い ま せ ん）。
ションで、独自のコーデックやメディア・プレーヤーを統合できるなど、
Stagefright は新しいオーディオ処理エレメントを使って拡張が可能です
商用利用にも有利な LGPLv2 ライセンスで提供されています。このフレー
が、GStreamer ほど柔軟性は高くありません。Stagefright プレーヤーの
ムワークは完全な機能を備えており、個々の処理エレメントを組み合わ
メディア処理グラフは、ソース、デマルチプレクサ（コンテナの解析）、デ
せて任意のメディア処理グラフを作成できます。コア・フレームワーク
コード・コンポーネントで固定されているため、任意のグラフの作成はで
以外にも、GStreamer にはすべての必要なオーディオとビデオ・フォー
きません。オーディオのミキシングとレンダリングはプレーヤー外部の
マットの処理エレメントを提供するプラグインが豊富に用意されていま
AudioFlinger コンポーネントによって処理されます。このコンポーネント
す。GStreamer は、入力ソース・ファイルまたはフォーマットと必要な
はオプションとしてプラグイン機能によるポストプロセッシングもサポー
出力シンクを指定するだけで完全なストリーミング・グラフを自動で作
トしています。Stagefright には数多くの一般的なコーデックのソースコー
成できるツールも提供しています。これらのツールは入力フォーマット
ドが含まれていますが、多くの場合、メーカーはこれを差し替えるか拡張し
を出力フォーマットに変換する際に必要となる中間コンポーネントをす
て独自のコーデック、特別に最適化したコーデック、あるいはハードウェ
べて自動で検出し、これらのコンポーネントを処理チェーンに挿入して
ア・アクセラレーションによるコーデックを使用するのが一般的です。こ
くれます。メディア・プレーヤーやその他のアプリケーション・ソフト
れ ら の 追 加 コ ン ポ ー ネ ン ト は Stagefright コ ー デ ッ ク API ま た は
ウェアは GStreamer ソリューションには含まれませんが、サードパー
OpenMAX-IL インターフェイスのどちらも実装できます。
ティから多くのプレーヤーが提供されています。グラフの自動作成機能
の関数を呼び出すか、またはコマンドラインから「gst-launch playbin
uri=file:<filename>」コマンドを実行するだけで簡単に再生できます。
Stagefright
プロトコル
- file:
- http:
- rtsp:
- ...
発されたもので、モバイル環境で一般的なほとんどのオーディオやビデオ・
GStreamerはオープンソースのマルチメディア・ソフトウェア・ソリュー
があるため、アプリケーションからファイルを再生する場合もいくつか
検証編
ディオの処理モジュールに対する制御関数が用意されています。
プレーヤーの置き換えとして数年前に Google によって Android 専用に開
Support Q&A
メモリーの利用を最適化する方法があります。しかし DSP のコードを最適
ア・ライセンスで提供されています。このフレームワークは、OpenCore
フィジカル編
フレームワーク関数、DSP 側で実行するように割り当てられた個々のオー
Stagefrightは、商用利用にも有利なAndroid標準のApache 2.0ソフトウェ
り上げ、それぞれを比較してみます。
Support Q&A
DSP固有の命令（intrinsic）を使用したり、キャッシュやその他のローカル・
GStreamer、Stagefright、OpenMAX-IL という 3 つのフレームワークを取
論理合成編
ト・プロセッサで利用可能にするプロキシ関数のみで構成されます。MSF
サポートを行っています [7]。
で は、唯 一 絶 対 の マ ル チ メ デ ィ ア 規 格 は 存 在 し ま せ ん。こ こ で は、
Support Q&A
のアーキテクチャを最大限に有効利用することも可能です。これには、
Android に移植し [6]、現在は GStreamer コミュニティがこれを継承して
最新技術情報
の MSF コンポーネントは、リモート DSP のインプリメンテーションをホス
「はじめに」で申し上げたように、細分化が進んだコンシューマ家電市場
かまいません。ある携帯電話の SoC メーカーが GStreamer プレーヤーを
Technology Update
トと対になるホスト側の RPC/IPC コンポーネントを使用します。ホスト側
DSP コアに関しては、エンジニアがソースコードをさらに最適化して DSP
ストリーミング
サーバ
オーディオ・レンダリング
（->AudioFlinger）
サポートしており、メディアの種類やその他のポリシーに基づいて専用の
ります。メディア・ストリーミング・フレームワーク上に構築されたオー
VoIPと
ビデオ会議
オーディオ
デコード
ターフェイスに変換します。以下、本稿ではこれらのコンポーネントについ
クに効率よく組み込むインテグレーション方法についてご説明します。
メディア
プレーヤー
ビデオ・レンダリング
（->SurfaceFlinger）
オーディオ処理モジュールが実装されるメディア・プレーヤーで必要なイン
るか、または HDMI™などのデジタル I/O ペリフェラルを経由して別のデバ
gst-inspect
gst-launch
gst-editor
ビデオ
デコード
図 6. Android におけるマルチメディア再生
最後に、もう 1 つの重要な要素としてオーディオ処理コンポーネントがあ
GStreamerツール
デマルチプレクサ
（コンテナの
フォーマットを解析）
Vorbis
プレーヤー
オートモーティブ
ソリューション
メッセージにシリアライズし、もう一方のコアのスタブ関数に渡します。
メディア・プレーヤー
アプリケーション
フレームワーク
最新技術情報
多くの製品では、ソフトウェア・スタックは DSP よりもホスト・プロセッ
Technology Update
ライアントは、送信データで共有メモリー・バッファを直接フィルし、完了
News Release
ホスト・アーキテクチャ
れば、送信側のクライアントはデータのコピーを防ぐことができます。ク
ニュースリリース
メディア・プレーヤー
アプリケーション
JAVA
へのポインタを返す「ゼロ・コピー」メッセージ・パッシング関数を使用す
OpenMAX-IL
本 稿 で 取 り 上 げ る 3 つ 目 の マ ル チ メ デ ィ ア・フ レ ー ム ワ ー ク が
OpenMAX-IL です。これは単一の実装方式をベースにしたフレームワー
クではなく、API規格で、業界コンソーシアムのクロノス・グループによっ
て定義が行われています（クロノス・グループはこのほかにも OpenGL®
StagefrightはAndroidの標準メディア・プレーヤーです。図6に示すように、
などのオープンで移植性を備えたいくつかのクロス・プラットフォーム
Android のマルチメディア・スタックは前述した例によく似ています。最
規格を定義しています）。OpenMAX-IL（Integration Layer）は、それぞ
上位には、メディア・プレーヤー・アプリとフレームワークで構成される
れ異なるソフトウェア・レイヤをターゲットとした 3 つの API 規格の 2 番
アプリケーション・スタックがあります。アプリはAndroid標準のメディア・
目に当たるものです。プレーヤー・レベルのインターフェイスを提供す
プレーヤー・アプリケーションで、フレームワークはネイティブなメディ
るのが OpenMAX-AL（Application Layer）で、DCT 変換などの演算カー
ア・プレーヤー・サービスへのJava™バインディングです。実際のメディア・
ネルを備えた低レベル・レイヤが OpenMAX-DL（Development Layer）
プ レ ー ヤ ー・イ ン プ リ メ ン テ ー シ ョ ン は こ の サ ー ビ ス に 含 ま れ ま す。
ですが、これらはいずれも本稿の内容には直接関係しないので説明を割
Android アーキテクチャは複数のプレーヤーのインプリメンテーションを
愛します。
次ページに続く
19
Technology Update
ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション
前ページより続く
したら IPC コンポーネントに通知します。
サ側の方がはるかに複雑です。ホスト・プロセッサは、オーディオ以外に
もビデオ、
（インターネット）通信、ストレージ、グラフィックス、ユーザー・
RPC（リモート・プロシージャ・コール）コンポーネントは IPC をさらに拡
インターフェイス、各種アプリケーション・ソフトウェアなどの機能を実
張したもので、IPC だけでは対処できない要求を満たします。メッセージ・
行しなければなりません。図 3（P17 参照）の左上は、オーディオ機能に焦
パッシングは通信媒体の細部を隠蔽しますが、一般にソフトウェア・モ
点を当てた一般的なマルチメディア・プレーヤーのアーキテクチャを示し
ジュールの通信向けプログラミング・パラダイムとしては自然ではありま
たものです。メディア・プレーヤー・クライアント・アプリケーションは
せん。その場合には C または C++ の関数呼び出しを使用します。RPC コン
GUI とアプリケーション・ロジックを提供し、この中にはプレイリスト管
ポーネントは、関数呼び出しのパラダイムをシングルコアからマルチコア
理やさらに高度なコンテンツ管理と再生 / 停止 / 一時停止 / シーク・コント
に拡張するためのインフラストラクチャを提供します。関数を呼び出すと、
ロールが含まれます。その下のメディア・プレーヤー・コンポーネントは、
その関数のインプリメンテーションを実行するのではなく、対応するプロ
実際のオーディオ再生機能やアプリケーションのその他のユースケース
キシ関数が呼び出され、このプロキシ関数が関数のすべての引数を 1 つの
（録音など）をインプリメントします。このコンポーネントは、一連の処理
コンポーネントを連結したチェーンを作成します。処理の内容としては、
このスタブ関数は引数をデシリアライズし、実際の実行環境を呼び出し、関
まずソース（SD カードに保存されたファイルやインターネット・ラジオ局
数の実行結果を最初のコアの関数呼び出し元へ返します。DesignWare
からのストリーミング・オーディオなど）から圧縮オーディオを読み出し、
SoundWave オーディオ・サブシステムで使用している RPC ソリューショ
次にオーディオ・フレームが含まれているコンテナ・フォーマットを解析
ンにはインターフェイス定義言語からプロキシ関数とスタブ関数を自動で
してオーディオ・フレームをアンパックします（オーディオ / ビデオ・スト
生成する機能があり、オブジェクトのライフサイクル・マネジメントやポ
リームのデマルチプレクスを実行）。次に、圧縮されたオーディオ・フレー
インタなど多くの引数タイプのマーシャリングをサポートしています。リ
ムをメディア・プレーヤー・コンポーネントがデコードし、さらにオプショ
モート関数の呼び出しは完全に透過的に行われ、ローカル関数を呼び出す
ンとしてオーディオ品質を補正したりチャネル数を調整するなどのポスト
のと同じくらい簡単に行えます。
プロセッシングを実行します。このチェーンの最後のコンポーネントは、
DAC を経由して Raw オーディオ・サンプルをスピーカにレンダリングす
Linuxユーザー空間
メディア・プレーヤー・サービス
…
メディア・プレーヤー
サービス
AudioFlinger
その他のオーディオ
ドライバ
Linuxカーネル空間
Stagefright
プレーヤー
GStreamer
プレーヤー
OpenCore
プレーヤー
MIDI
プレーヤー
Alsaカーネル
ドライバ
リーダ
（ソースから読み出し）
プレーヤーが呼び出されます。標準のプレーヤーは Stagefright ですが、機
て詳しくご説明します。まず 3 つの業界標準マルチメディア・フレームワー
器メーカーが別のより高機能なプレーヤーやメーカー固有のハードウェア
クをご紹介した後で、DSP ベースのオーディオ処理をこれらのフレームワー
に最適化したプレーヤーをサービスにプラグイン形式で追加することもで
きます。ここで追加するプレーヤーは、メーカー独自またはレガシーのソ
イスやストレージに転送します。
一般に、設計者は最初から特定のホスト CPU や DSP に合わせてアルゴリズ
図 3（P17 参照）の左下は、ホスト・プロセッサのインフラストラクチャ・
ムを作成するのではなく、まず通常の C コードでアルゴリズムを記述しま
コンポーネントを示しています。ここでは、Linux、Windows®、iOS など
マルチメディア・フレームワークとAPI
す。最近のコンパイラは、このソースコードをもとに特定のプロセッサに
汎用オペレーティング・システムの組み込み版がよく使用されます。
（リ
合わせて高度に最適化した実装を行えます。
モート化された）MSF コンポーネントは、DSP 側の RPC/IPC コンポーネン
リューションでも、あるいはオープンソースの GStreamer プレーヤーでも
ディオ処理コンポーネントは、オーディオ処理アルゴリズムを実装します。
化して最大限の性能を引き出す作業は非常に高い専門性が要求されます。
このため、必要なオーディオ・コーデックやポストプロセッシング・アル
残りのコンポーネント、すなわちデコーダ・ラッパとポストプロセッシン
ゴリズムは DSP サプライヤから提供されるのが理想的です。
グ・プラグインは、MSF レイヤによって提供されるインターフェイスを、
マルチメディア・アプリケーション
GStreamerコア・フレームワーク
パイプライン・アーキテクチャ
ビデオ
エディタ
(...)
メディア非依存
ベース・クラス
メッセージ・バス
メディア・タイプ・ネゴシエーション
プラグイン・システム
ユーティリティ・ライブラリ
言語バインディング
GStreamer
ソース
- alsa
- v4l2
- tcp/upd
- ...
フォーマット
- avi
- mp4
- ogg
- ...
コーデック
- mp3
- mpeg4
- vorbis
- ...
フィルタ
- converters
- mixers
- effects
- ...
GStreamerプラグイン
GStreamerに含まれる150以上のプラグイン
図 5. GStreamer マルチメディア・フレームワーク
18
シンク
- alsa
- xvideo
- tcp/udp
- ...
(...)
サードパーティ製
プラグイン
フォーマットの再生をサポートしています（ただし Blu-Ray HD オーディ
オ・コ ー デ ッ ク と マ ル チ チ ャ ネ ル 出 力 は サ ポ ー ト し て い ま せ ん）。
ションで、独自のコーデックやメディア・プレーヤーを統合できるなど、
Stagefright は新しいオーディオ処理エレメントを使って拡張が可能です
商用利用にも有利な LGPLv2 ライセンスで提供されています。このフレー
が、GStreamer ほど柔軟性は高くありません。Stagefright プレーヤーの
ムワークは完全な機能を備えており、個々の処理エレメントを組み合わ
メディア処理グラフは、ソース、デマルチプレクサ（コンテナの解析）、デ
せて任意のメディア処理グラフを作成できます。コア・フレームワーク
コード・コンポーネントで固定されているため、任意のグラフの作成はで
以外にも、GStreamer にはすべての必要なオーディオとビデオ・フォー
きません。オーディオのミキシングとレンダリングはプレーヤー外部の
マットの処理エレメントを提供するプラグインが豊富に用意されていま
AudioFlinger コンポーネントによって処理されます。このコンポーネント
す。GStreamer は、入力ソース・ファイルまたはフォーマットと必要な
はオプションとしてプラグイン機能によるポストプロセッシングもサポー
出力シンクを指定するだけで完全なストリーミング・グラフを自動で作
トしています。Stagefright には数多くの一般的なコーデックのソースコー
成できるツールも提供しています。これらのツールは入力フォーマット
ドが含まれていますが、多くの場合、メーカーはこれを差し替えるか拡張し
を出力フォーマットに変換する際に必要となる中間コンポーネントをす
て独自のコーデック、特別に最適化したコーデック、あるいはハードウェ
べて自動で検出し、これらのコンポーネントを処理チェーンに挿入して
ア・アクセラレーションによるコーデックを使用するのが一般的です。こ
くれます。メディア・プレーヤーやその他のアプリケーション・ソフト
れ ら の 追 加 コ ン ポ ー ネ ン ト は Stagefright コ ー デ ッ ク API ま た は
ウェアは GStreamer ソリューションには含まれませんが、サードパー
OpenMAX-IL インターフェイスのどちらも実装できます。
ティから多くのプレーヤーが提供されています。グラフの自動作成機能
の関数を呼び出すか、またはコマンドラインから「gst-launch playbin
uri=file:<filename>」コマンドを実行するだけで簡単に再生できます。
Stagefright
プロトコル
- file:
- http:
- rtsp:
- ...
発されたもので、モバイル環境で一般的なほとんどのオーディオやビデオ・
GStreamerはオープンソースのマルチメディア・ソフトウェア・ソリュー
があるため、アプリケーションからファイルを再生する場合もいくつか
検証編
ディオの処理モジュールに対する制御関数が用意されています。
プレーヤーの置き換えとして数年前に Google によって Android 専用に開
Support Q&A
メモリーの利用を最適化する方法があります。しかし DSP のコードを最適
ア・ライセンスで提供されています。このフレームワークは、OpenCore
フィジカル編
フレームワーク関数、DSP 側で実行するように割り当てられた個々のオー
Stagefrightは、商用利用にも有利なAndroid標準のApache 2.0ソフトウェ
り上げ、それぞれを比較してみます。
Support Q&A
DSP固有の命令（intrinsic）を使用したり、キャッシュやその他のローカル・
GStreamer、Stagefright、OpenMAX-IL という 3 つのフレームワークを取
論理合成編
ト・プロセッサで利用可能にするプロキシ関数のみで構成されます。MSF
サポートを行っています [7]。
で は、唯 一 絶 対 の マ ル チ メ デ ィ ア 規 格 は 存 在 し ま せ ん。こ こ で は、
Support Q&A
のアーキテクチャを最大限に有効利用することも可能です。これには、
Android に移植し [6]、現在は GStreamer コミュニティがこれを継承して
最新技術情報
の MSF コンポーネントは、リモート DSP のインプリメンテーションをホス
「はじめに」で申し上げたように、細分化が進んだコンシューマ家電市場
かまいません。ある携帯電話の SoC メーカーが GStreamer プレーヤーを
Technology Update
トと対になるホスト側の RPC/IPC コンポーネントを使用します。ホスト側
DSP コアに関しては、エンジニアがソースコードをさらに最適化して DSP
ストリーミング
サーバ
オーディオ・レンダリング
（->AudioFlinger）
サポートしており、メディアの種類やその他のポリシーに基づいて専用の
ります。メディア・ストリーミング・フレームワーク上に構築されたオー
VoIPと
ビデオ会議
オーディオ
デコード
ターフェイスに変換します。以下、本稿ではこれらのコンポーネントについ
クに効率よく組み込むインテグレーション方法についてご説明します。
メディア
プレーヤー
ビデオ・レンダリング
（->SurfaceFlinger）
オーディオ処理モジュールが実装されるメディア・プレーヤーで必要なイン
るか、または HDMI™などのデジタル I/O ペリフェラルを経由して別のデバ
gst-inspect
gst-launch
gst-editor
ビデオ
デコード
図 6. Android におけるマルチメディア再生
最後に、もう 1 つの重要な要素としてオーディオ処理コンポーネントがあ
GStreamerツール
デマルチプレクサ
（コンテナの
フォーマットを解析）
Vorbis
プレーヤー
オートモーティブ
ソリューション
メッセージにシリアライズし、もう一方のコアのスタブ関数に渡します。
メディア・プレーヤー
アプリケーション
フレームワーク
最新技術情報
多くの製品では、ソフトウェア・スタックは DSP よりもホスト・プロセッ
Technology Update
ライアントは、送信データで共有メモリー・バッファを直接フィルし、完了
News Release
ホスト・アーキテクチャ
れば、送信側のクライアントはデータのコピーを防ぐことができます。ク
ニュースリリース
メディア・プレーヤー
アプリケーション
JAVA
へのポインタを返す「ゼロ・コピー」メッセージ・パッシング関数を使用す
OpenMAX-IL
本 稿 で 取 り 上 げ る 3 つ 目 の マ ル チ メ デ ィ ア・フ レ ー ム ワ ー ク が
OpenMAX-IL です。これは単一の実装方式をベースにしたフレームワー
クではなく、API規格で、業界コンソーシアムのクロノス・グループによっ
て定義が行われています（クロノス・グループはこのほかにも OpenGL®
StagefrightはAndroidの標準メディア・プレーヤーです。図6に示すように、
などのオープンで移植性を備えたいくつかのクロス・プラットフォーム
Android のマルチメディア・スタックは前述した例によく似ています。最
規格を定義しています）。OpenMAX-IL（Integration Layer）は、それぞ
上位には、メディア・プレーヤー・アプリとフレームワークで構成される
れ異なるソフトウェア・レイヤをターゲットとした 3 つの API 規格の 2 番
アプリケーション・スタックがあります。アプリはAndroid標準のメディア・
目に当たるものです。プレーヤー・レベルのインターフェイスを提供す
プレーヤー・アプリケーションで、フレームワークはネイティブなメディ
るのが OpenMAX-AL（Application Layer）で、DCT 変換などの演算カー
ア・プレーヤー・サービスへのJava™バインディングです。実際のメディア・
ネルを備えた低レベル・レイヤが OpenMAX-DL（Development Layer）
プ レ ー ヤ ー・イ ン プ リ メ ン テ ー シ ョ ン は こ の サ ー ビ ス に 含 ま れ ま す。
ですが、これらはいずれも本稿の内容には直接関係しないので説明を割
Android アーキテクチャは複数のプレーヤーのインプリメンテーションを
愛します。
次ページに続く
19
Technology Update
ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション
前ページより続く
示しています（「G」と書かれたコンポーネント）。ディープ・トンネルで実
フレームワーク
コンポーネント
フレームワーク
コンポーネント
フレームワーク
コンポーネント
トンネル通信
ソース
コンポーネント
ホスト
コンポーネント
ンフラストラクチャを利用して）DSP 側に対応するコンポーネントを作成
します（図 8 で「M」と書かれたコンポーネント）。DSP MSF は同じ DSP で
実行するように割り当てられているコンポーネント間の接続はすべてロー
カルにインプリメントするため、システムはデータ・ストリーミング時の
アクセラレータ
コンポーネント
コア間通信を最小限に抑えられます。コア間の通信が必要な場合、ホスト
フレームワーク
コンポーネント
IPC
非トンネル通信
ホスト側でインスタンス化されると、このコンポーネントは（RPC/IPC イ
OpenMAXコア
フレームワーク
コンポーネント
装された仮想データフロー接続も破線で示しています。コンポーネントが
側のコンポーネントはオーディオ処理コンポーネントだけでなく、トンネ
ルの実装に必要なプロセッサ間データ・バッファ、ソース、シンク・コンポー
IPC
ネントも作成します。これはホスト・コンポーネントの内部実装の一部で
あるため、ホスト・プロセッサ側のコンポーネントを使用しているクライ
ハードウェア
アクセラレーション
コーデック
アント・アプリケーションからは完全に意識される必要がありません。
ホストCPU
トンネル通信
図 7. OpenMAX-IL フレームワークのアーキテクチャ
てローカルの DSP 上に保持し、消費電力を最小限に抑えて最大限の性能を
のデータフロー・グラフが固定されておらず、個々の処理エレメントを組
発揮するといった用途には適していません。
み 合 わ せ て 任 意 の グ ラ フ を 作 成 で き る と い う 点 で、OpenMAX-IL は
GStreamer
GStreamer と共通しています。エレメント間のメディア・データ交換のイ
ンターフェイスとプロトコル以外にも、OpenMAX-IL はメディア・フォー
マット、入力 / 出力ポート、そして MP3 デコーダやオーディオ・ミキサなど
特定のエレメント用のコマンドも標準化しています。
シンク
表 1. 各フレームワークの比較
ンネル通信は、クライアントがユースケースに合わせてインスタンス化し
DSP へのオフロードをサポートしているかどうかという点です。ここに挙
たフレームワーク・コンポーネントにより、クライアント・アプリケーショ
げた 3 つのソリューションは、いずれも標準ではヘテロジニアス・マルチ
ンを通じてデータを転送します。このプロトコルは移植性が最も高い反面、
コア・ハードウェア・アーキテクチャをサポートしておらず、インターオ
多くのデータ・コピーが発生するため効率は最も悪くなります。トンネル
ペラビリティがある OpenMAX-IL のトンネル通信もサポートしていませ
通信は、データ（へのポインタ）を実装コンポーネント間で直接通信すると、
ん。しかしこれらのフレームワークはいずれもオーディオ処理モジュール
データ・コピーとクライアント・アプリケーションの関与をなくしています。
を特定のプラットフォームに合わせて最適化した実装方式をサポートして
図 7 には、2 種類のトンネル通信が示されています。1 つは OpenMAX-IL 規
おり、ディープ・トンネル通信にも対応します。次のセクションで詳しく
格によって完全に定義された、インターオペラビリティのあるトンネル通
ご紹介しますが、コーデックのオフロードとディープ・トンネル通信は
信で、もう 1 つはプラットフォームを実装する際にターゲット・ハードウェ
GStreamer と OpenMAX とで高い親和性があります。Stagefright の場合
アに合わせて最適な定義を行えるプラットフォーム固有のトンネル通信で
は処理チェーンが固定されており、ポストプロセッシングとレンダリング
す。後者はディープ・トンネル通信とも呼ばれ、通常はこのプロトコルが
をプレーヤー外部の独立した AudioFlinger コンポーネントで実行している
最も効率は良くなります。ただし、標準規格に基づいていないため、イン
ため、GStreamer や OpenMAX より多くの修正が必要になります。
SoCへのオーディオ・サブシステムの
ソフトウェア・インテグレーション
個々の製品でどのマルチメディア・フレームワークを使用するかは、表 1
このセクションでは、DSP ベースのオーディオ・サブシステムをより大規
に示したいくつかの要因を考慮して決める必要があります。プログラマの
模な SoC に組み込むソフトウェア・インテグレーションの方法ついて詳し
立場から重視すべき点は、クロス・フレームワークのサポートと DSP オフ
くご説明します。ここでの説明では、先にご説明した全体的なヘテロジニ
ロ ー ド の 2 つ で す。GStreamer と Stagefright は ど ち ら も OpenMAX-IL
アス・マルチメディア・ソフトウェア・アーキテクチャとホスト CPU マル
コ ン ポ ー ネ ン ト を ク ロ ス・フ レ ー ム ワ ー ク で 使 用 で き ま す。た だ し
チメディア・フレームワークの使用を前提とします。まず、効率を考慮し
OpenMAX はそれ自体が完全なマルチメディア・フレームワークであるた
てデータをローカルに保持するため、アナログ / デジタル・オーディオの入
め、これらのフレームワークをスタックすると機能の重複、複雑さの増大、
出力を含めすべてのオーディオ処理をサブシステムに実装します。サブシ
オーバーヘッドの増加といった問題が生じます。ある SoC メーカーの報告
ステムは、1 つ以上の DSP（ARC AS211SFX/AS221BD オーディオ・プロ
によると、GStreamer OpenMAX ラッパ・ベースのソリューションの代
セッサなど）、オーディオ I/O ペリフェラル、そして DSP 処理とホスト・ソ
わりにGStreamerエレメントを使ってネイティブなコーデック・インター
フトウェア・インターフェイス用のソフトウェア・コンポーネント一式で
フェイスを直接使用したところ、性能が30%向上したといいます。一般に、
構成されます。図 8 は、2 つの DSP を使用したシステムのコンポーネント
OpenMAX 規格は他のメディア処理フレームワークと組み合わせて使うに
のデータフロー・グラフの概念図を示したものです。
は複雑すぎると設計者の間では考えられています。Stagefright OpenMAX
20
ディオ・サブシステムに含まれる GStreamer プラグインのソースコード・
ソリューションはディープ・トンネル通信をサポートしていないため、な
ホスト・ソフトウェア・スタックから見ると、システムはシングルコア・
るべく多くのデータをヘテロジニアス・マルチコア・ソリューションによっ
シ ス テ ム と 何 ら 変 わ り ま せ ん。コ ン ポ ー ネ ン ト は、マ ル チ メ デ ィ ア・
ARC - ARC間
ストリーミング
FIFO
ドライバ
ARCコア#0
ARCコア#1
ARC AS221BDオーディオ・プロセッサに
インスタンス化したデータフロー・グラフ
検証編
モバイル
次に考慮しなくてはならないのは、フレームワークがオーディオ処理の
各フレームワークの比較
効率よく変換する方法をご紹介するため、DesignWare SoundWave オー
ソース
Support Q&A
モバイル
ンポーネント間通信により、効率的で移植性の高い実装が可能です。非ト
ターオペラビリティはありません。
のホスト・マルチメディア・フレームワークで必要な API にシンプルかつ
（ただし専用のインプリメンテーションで可能）
すべて
図 9. GStreamer オーディオ・エレメントのディープ・トンネル通信のソースコード例
フィジカル編
×
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, ...);
}
}
図 9 は、適切に選択した DSP マルチメディア・ストリーミング API を特定
ソース
○
×
connect_msf_outpin (GstPad* pad)
{
GstAudioModule *filter = …; // this elements private data
Support Q&A
提供します。非トンネル、トンネル、ディープ・トンネルという 3 種類のコ
○
ンなど、多くの機器がこのような構成を採用しています。
論理合成編
カル CPU とリモートのどちらに実装しても、常に同じインターフェイスを
アプリケーション領域
○
用することをお奨めします。事実、Google TV™デバイスやスマートフォ
Support Q&A
アルゴリズムをハードウェアとソフトウェアのどちらに実装しても、ロー
ヘテロジニアス
マルチコアのサポート
×
（ただしOMXコンポーネントを使用可）
ホスト- ARC間
ストリーミング
FIFO
ションでは、Stagefright の代わりに Android GStreamer プレーヤーを使
最新技術情報
ラットフォーム・インターフェイスとなることを目標に設計されています。
グラフの柔軟性
OpenMAX-IL
オーディオや複雑な処理グラフを使用するような要求の厳しいアプリケー
Technology Update
OpenMAX-IL は、メディア処理実装方式に左右されない標準のクロス・プ
APIの標準化
Stagefright
ホーム・オーディオ/ビデオ・アプリケーションなど、HD/マルチチャネル・
オートモーティブ
ソリューション
図 7 は、OpenMAX-IL フレームワークのアーキテクチャです。プレーヤー
ンネル通信も必要ありません。
最新技術情報
るコンポーネントの単なるプロキシに過ぎません。これを図 8 では破線で
で基本的な OpenMAX-IL コンポーネントを組み合わせるだけで十分で、ト
Technology Update
マルチメディア・フレームワーク
ます。ただし、ホスト側のいくつかのコンポーネントは、DSP 側で動作す
News Release
フレームワークの通常の呼び出しによってインスタンス化、接続、制御され
ニュースリリース
ILクライアント
フラグメントを示したものです。このフラグメントは、2 つのメディア処理
エレメントを連結する GStreamer の「ピン接続」関数をインプリメントし
ています。この関数は、接続のタイプに応じて追加のシンク・コンポーネ
ントを作成し、ピンを接続して（ディープ）トンネルを形成します。通常は
オーディオ処理をインプリメントする GStreamer の「チェーン」または
「ループ」関数の実装もシンプルです。これはディープ・トンネルの場合に
は無効になり、ホスト CPU に割り当てられた部分と DSP に割り当てられた
ローカル
ストリーミング
図 8. ヘテロジニアス・マルチコア SoC におけるオーディオ・データフロー・グラフの概念図
ホスト・プロセッサ側でどのマルチメディア・フレームワークを使用する
かによって、ホスト・コンポーネントの必要な実装方式が決まります。
GStreamer と Stagefright で同じ OpenMAX-IL ベースのコンポーネントを
使用することもできますが、複雑になるだけで性能も低下するため推奨で
きません。しかも、OpenMAX-ILが標準化しているのはモバイル分野のオー
部分の境界に位置するコンポーネントの場合はデータをコア間通信バッ
ファに送信します。
まとめ
市場をリードするハイエンド・オーディオ製品を投入するには、正しいソ
フトウェア・ソリューション選びが欠かせません。処理性能と開発の手間
の両方の意味で効率的なハイエンド・オーディオ製品を開発するには、数
多くのソフトウェアを使用する必要があります。本稿でご説明したように、
ディオ・コンポーネントの一部にすぎません。
オーディオ処理を ARC AS211SFX/AS221BD オーディオ・プロセッサな
プログラマは、RPC/IPC と DSP MSF インフラストラクチャ、DSP に最適化
ア・アーキテクチャを使用すれば、システム・インテグレータやアプリケー
したオーディオ処理モジュールを利用して、個々のフレームワークに最適
化 し た ホ ス ト・コ ン ポ ー ネ ン ト を 比 較 的 シ ン プ ル に 実 装 で き ま す。
GStreamer の場合は、前述のように MSF 関数を直接呼び出し、
（ディープ）
トンネル通信を形成するエレメントを使ってプラグイン・モジュールを実
装するのが最適なソリューションです。同様に、OpenMAX-IL の場合は
MSF を使って独自のディープ・トンネル・プロトコルを実装したコンポー
ネントが最適です。Android の場合、最適なソリューションはアプリケー
ション分野によって異なります。オーディオ処理の要件がそれほど厳しく
ないモバイル・アプリケーションの場合は、標準の Stagefright とシンプル
どの DSP にオフロードした場合でも、最適なマルチメディア・ソフトウェ
ション・プログラマはソフトウェアの複雑性を意識しなくて済みます。リ
アルタイム OS、マルチメディア・ストリーミング・フレームワーク、最適
化済みオーディオ・コーデックや処理関数のライブラリ、プロセッサ間通
信（IPC）、そして一般的に使用されるマルチメディア API のインターフェ
イス・レイヤを統合したソリューションを使えば、システム・インテグレー
タやアプリケーション開発者からハイエンド・オーディオの複雑さを隠蔽
できます。オーディオ・サブシステムを SoC に組み込むソフトウェア・イ
ンテグレーションも簡単な作業で容易に行え、現在から将来にわたって
オーディオ領域の課題に対処できます。
参考文献
[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.
21
Technology Update
ハイエンド・オーディオ機能を手軽に実現するソフトウェア・ソリューション
前ページより続く
示しています（「G」と書かれたコンポーネント）。ディープ・トンネルで実
フレームワーク
コンポーネント
フレームワーク
コンポーネント
フレームワーク
コンポーネント
トンネル通信
ソース
コンポーネント
ホスト
コンポーネント
ンフラストラクチャを利用して）DSP 側に対応するコンポーネントを作成
します（図 8 で「M」と書かれたコンポーネント）。DSP MSF は同じ DSP で
実行するように割り当てられているコンポーネント間の接続はすべてロー
カルにインプリメントするため、システムはデータ・ストリーミング時の
アクセラレータ
コンポーネント
コア間通信を最小限に抑えられます。コア間の通信が必要な場合、ホスト
フレームワーク
コンポーネント
IPC
非トンネル通信
ホスト側でインスタンス化されると、このコンポーネントは（RPC/IPC イ
OpenMAXコア
フレームワーク
コンポーネント
装された仮想データフロー接続も破線で示しています。コンポーネントが
側のコンポーネントはオーディオ処理コンポーネントだけでなく、トンネ
ルの実装に必要なプロセッサ間データ・バッファ、ソース、シンク・コンポー
IPC
ネントも作成します。これはホスト・コンポーネントの内部実装の一部で
あるため、ホスト・プロセッサ側のコンポーネントを使用しているクライ
ハードウェア
アクセラレーション
コーデック
アント・アプリケーションからは完全に意識される必要がありません。
ホストCPU
トンネル通信
図 7. OpenMAX-IL フレームワークのアーキテクチャ
てローカルの DSP 上に保持し、消費電力を最小限に抑えて最大限の性能を
のデータフロー・グラフが固定されておらず、個々の処理エレメントを組
発揮するといった用途には適していません。
み 合 わ せ て 任 意 の グ ラ フ を 作 成 で き る と い う 点 で、OpenMAX-IL は
GStreamer
GStreamer と共通しています。エレメント間のメディア・データ交換のイ
ンターフェイスとプロトコル以外にも、OpenMAX-IL はメディア・フォー
マット、入力 / 出力ポート、そして MP3 デコーダやオーディオ・ミキサなど
特定のエレメント用のコマンドも標準化しています。
シンク
表 1. 各フレームワークの比較
ンネル通信は、クライアントがユースケースに合わせてインスタンス化し
DSP へのオフロードをサポートしているかどうかという点です。ここに挙
たフレームワーク・コンポーネントにより、クライアント・アプリケーショ
げた 3 つのソリューションは、いずれも標準ではヘテロジニアス・マルチ
ンを通じてデータを転送します。このプロトコルは移植性が最も高い反面、
コア・ハードウェア・アーキテクチャをサポートしておらず、インターオ
多くのデータ・コピーが発生するため効率は最も悪くなります。トンネル
ペラビリティがある OpenMAX-IL のトンネル通信もサポートしていませ
通信は、データ（へのポインタ）を実装コンポーネント間で直接通信すると、
ん。しかしこれらのフレームワークはいずれもオーディオ処理モジュール
データ・コピーとクライアント・アプリケーションの関与をなくしています。
を特定のプラットフォームに合わせて最適化した実装方式をサポートして
図 7 には、2 種類のトンネル通信が示されています。1 つは OpenMAX-IL 規
おり、ディープ・トンネル通信にも対応します。次のセクションで詳しく
格によって完全に定義された、インターオペラビリティのあるトンネル通
ご紹介しますが、コーデックのオフロードとディープ・トンネル通信は
信で、もう 1 つはプラットフォームを実装する際にターゲット・ハードウェ
GStreamer と OpenMAX とで高い親和性があります。Stagefright の場合
アに合わせて最適な定義を行えるプラットフォーム固有のトンネル通信で
は処理チェーンが固定されており、ポストプロセッシングとレンダリング
す。後者はディープ・トンネル通信とも呼ばれ、通常はこのプロトコルが
をプレーヤー外部の独立した AudioFlinger コンポーネントで実行している
最も効率は良くなります。ただし、標準規格に基づいていないため、イン
ため、GStreamer や OpenMAX より多くの修正が必要になります。
SoCへのオーディオ・サブシステムの
ソフトウェア・インテグレーション
個々の製品でどのマルチメディア・フレームワークを使用するかは、表 1
このセクションでは、DSP ベースのオーディオ・サブシステムをより大規
に示したいくつかの要因を考慮して決める必要があります。プログラマの
模な SoC に組み込むソフトウェア・インテグレーションの方法ついて詳し
立場から重視すべき点は、クロス・フレームワークのサポートと DSP オフ
くご説明します。ここでの説明では、先にご説明した全体的なヘテロジニ
ロ ー ド の 2 つ で す。GStreamer と Stagefright は ど ち ら も OpenMAX-IL
アス・マルチメディア・ソフトウェア・アーキテクチャとホスト CPU マル
コ ン ポ ー ネ ン ト を ク ロ ス・フ レ ー ム ワ ー ク で 使 用 で き ま す。た だ し
チメディア・フレームワークの使用を前提とします。まず、効率を考慮し
OpenMAX はそれ自体が完全なマルチメディア・フレームワークであるた
てデータをローカルに保持するため、アナログ / デジタル・オーディオの入
め、これらのフレームワークをスタックすると機能の重複、複雑さの増大、
出力を含めすべてのオーディオ処理をサブシステムに実装します。サブシ
オーバーヘッドの増加といった問題が生じます。ある SoC メーカーの報告
ステムは、1 つ以上の DSP（ARC AS211SFX/AS221BD オーディオ・プロ
によると、GStreamer OpenMAX ラッパ・ベースのソリューションの代
セッサなど）、オーディオ I/O ペリフェラル、そして DSP 処理とホスト・ソ
わりにGStreamerエレメントを使ってネイティブなコーデック・インター
フトウェア・インターフェイス用のソフトウェア・コンポーネント一式で
フェイスを直接使用したところ、性能が30%向上したといいます。一般に、
構成されます。図 8 は、2 つの DSP を使用したシステムのコンポーネント
OpenMAX 規格は他のメディア処理フレームワークと組み合わせて使うに
のデータフロー・グラフの概念図を示したものです。
は複雑すぎると設計者の間では考えられています。Stagefright OpenMAX
20
ディオ・サブシステムに含まれる GStreamer プラグインのソースコード・
ソリューションはディープ・トンネル通信をサポートしていないため、な
ホスト・ソフトウェア・スタックから見ると、システムはシングルコア・
るべく多くのデータをヘテロジニアス・マルチコア・ソリューションによっ
シ ス テ ム と 何 ら 変 わ り ま せ ん。コ ン ポ ー ネ ン ト は、マ ル チ メ デ ィ ア・
ARC - ARC間
ストリーミング
FIFO
ドライバ
ARCコア#0
ARCコア#1
ARC AS221BDオーディオ・プロセッサに
インスタンス化したデータフロー・グラフ
検証編
モバイル
次に考慮しなくてはならないのは、フレームワークがオーディオ処理の
各フレームワークの比較
効率よく変換する方法をご紹介するため、DesignWare SoundWave オー
ソース
Support Q&A
モバイル
ンポーネント間通信により、効率的で移植性の高い実装が可能です。非ト
ターオペラビリティはありません。
のホスト・マルチメディア・フレームワークで必要な API にシンプルかつ
（ただし専用のインプリメンテーションで可能）
すべて
図 9. GStreamer オーディオ・エレメントのディープ・トンネル通信のソースコード例
フィジカル編
×
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, ...);
}
}
図 9 は、適切に選択した DSP マルチメディア・ストリーミング API を特定
ソース
○
×
connect_msf_outpin (GstPad* pad)
{
GstAudioModule *filter = …; // this elements private data
Support Q&A
提供します。非トンネル、トンネル、ディープ・トンネルという 3 種類のコ
○
ンなど、多くの機器がこのような構成を採用しています。
論理合成編
カル CPU とリモートのどちらに実装しても、常に同じインターフェイスを
アプリケーション領域
○
用することをお奨めします。事実、Google TV™デバイスやスマートフォ
Support Q&A
アルゴリズムをハードウェアとソフトウェアのどちらに実装しても、ロー
ヘテロジニアス
マルチコアのサポート
×
（ただしOMXコンポーネントを使用可）
ホスト- ARC間
ストリーミング
FIFO
ションでは、Stagefright の代わりに Android GStreamer プレーヤーを使
最新技術情報
ラットフォーム・インターフェイスとなることを目標に設計されています。
グラフの柔軟性
OpenMAX-IL
オーディオや複雑な処理グラフを使用するような要求の厳しいアプリケー
Technology Update
OpenMAX-IL は、メディア処理実装方式に左右されない標準のクロス・プ
APIの標準化
Stagefright
ホーム・オーディオ/ビデオ・アプリケーションなど、HD/マルチチャネル・
オートモーティブ
ソリューション
図 7 は、OpenMAX-IL フレームワークのアーキテクチャです。プレーヤー
ンネル通信も必要ありません。
最新技術情報
るコンポーネントの単なるプロキシに過ぎません。これを図 8 では破線で
で基本的な OpenMAX-IL コンポーネントを組み合わせるだけで十分で、ト
Technology Update
マルチメディア・フレームワーク
ます。ただし、ホスト側のいくつかのコンポーネントは、DSP 側で動作す
News Release
フレームワークの通常の呼び出しによってインスタンス化、接続、制御され
ニュースリリース
ILクライアント
フラグメントを示したものです。このフラグメントは、2 つのメディア処理
エレメントを連結する GStreamer の「ピン接続」関数をインプリメントし
ています。この関数は、接続のタイプに応じて追加のシンク・コンポーネ
ントを作成し、ピンを接続して（ディープ）トンネルを形成します。通常は
オーディオ処理をインプリメントする GStreamer の「チェーン」または
「ループ」関数の実装もシンプルです。これはディープ・トンネルの場合に
は無効になり、ホスト CPU に割り当てられた部分と DSP に割り当てられた
ローカル
ストリーミング
図 8. ヘテロジニアス・マルチコア SoC におけるオーディオ・データフロー・グラフの概念図
ホスト・プロセッサ側でどのマルチメディア・フレームワークを使用する
かによって、ホスト・コンポーネントの必要な実装方式が決まります。
GStreamer と Stagefright で同じ OpenMAX-IL ベースのコンポーネントを
使用することもできますが、複雑になるだけで性能も低下するため推奨で
きません。しかも、OpenMAX-ILが標準化しているのはモバイル分野のオー
部分の境界に位置するコンポーネントの場合はデータをコア間通信バッ
ファに送信します。
まとめ
市場をリードするハイエンド・オーディオ製品を投入するには、正しいソ
フトウェア・ソリューション選びが欠かせません。処理性能と開発の手間
の両方の意味で効率的なハイエンド・オーディオ製品を開発するには、数
多くのソフトウェアを使用する必要があります。本稿でご説明したように、
ディオ・コンポーネントの一部にすぎません。
オーディオ処理を ARC AS211SFX/AS221BD オーディオ・プロセッサな
プログラマは、RPC/IPC と DSP MSF インフラストラクチャ、DSP に最適化
ア・アーキテクチャを使用すれば、システム・インテグレータやアプリケー
したオーディオ処理モジュールを利用して、個々のフレームワークに最適
化 し た ホ ス ト・コ ン ポ ー ネ ン ト を 比 較 的 シ ン プ ル に 実 装 で き ま す。
GStreamer の場合は、前述のように MSF 関数を直接呼び出し、
（ディープ）
トンネル通信を形成するエレメントを使ってプラグイン・モジュールを実
装するのが最適なソリューションです。同様に、OpenMAX-IL の場合は
MSF を使って独自のディープ・トンネル・プロトコルを実装したコンポー
ネントが最適です。Android の場合、最適なソリューションはアプリケー
ション分野によって異なります。オーディオ処理の要件がそれほど厳しく
ないモバイル・アプリケーションの場合は、標準の Stagefright とシンプル
どの DSP にオフロードした場合でも、最適なマルチメディア・ソフトウェ
ション・プログラマはソフトウェアの複雑性を意識しなくて済みます。リ
アルタイム OS、マルチメディア・ストリーミング・フレームワーク、最適
化済みオーディオ・コーデックや処理関数のライブラリ、プロセッサ間通
信（IPC）、そして一般的に使用されるマルチメディア API のインターフェ
イス・レイヤを統合したソリューションを使えば、システム・インテグレー
タやアプリケーション開発者からハイエンド・オーディオの複雑さを隠蔽
できます。オーディオ・サブシステムを SoC に組み込むソフトウェア・イ
ンテグレーションも簡単な作業で容易に行え、現在から将来にわたって
オーディオ領域の課題に対処できます。
参考文献
[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.
21
© Copyright 2024 Paperzz
