technology update - synopsys · 2020. 7. 30. · technology update 16 17...

最新技術情報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 のソースコード例

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

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

メディア・プレーヤー

リーダ

レンダラ

デコーダラッパ

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

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

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

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

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

MSFフレームワーク

MQX OS

RPC/IPC

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

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

次ページに続く

アプリケーション

ビデオ

グラフィックス

オーディオプラグイン

OS

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

デコード +

エンコード

ソース +

シンク

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

ペリフェラルとクロック

ポストプロセッシング

オーディオレンダリング

汎用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コンポーネントは割り込みハンドラやその他の低レベルな細部を処理してくれます。効率を重視して、共有メモリー・バッファ

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

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

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

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

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

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

メディア・プレーヤー

リーダ

レンダラ

デコーダラッパ

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

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

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

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

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

MSFフレームワーク

MQX OS

RPC/IPC

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

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

次ページに続く

アプリケーション

ビデオ

グラフィックス

オーディオプラグイン

OS

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

デコード +

エンコード

ソース +

シンク

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

ペリフェラルとクロック

オーディオレンダリング

汎用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）

…