リアルタイム音響処理を 成功に導く方法

Technical Article リアルタイム音響処理を 成功に導く方法 著者：David Katz、インフォテインメント・システム・アーキテクチャ担当ディレクタ 多くの組み込みアプリケーションにおいて、リアルタイムの音響 ん。そのため、車両と道路の接触に伴って生じる音が非常に耳障 処理は非常に重要な要素となっています。具体的な例としては、 りなものになっているのです。このような騒音を低減すれば、よ 音声の前処理、音声認識、ANC（Active Noise Cancellation） り快適な乗り心地が得られます。結果として、ドライバーの疲労 などが挙げられます。これらのアプリケーション領域では、リア を軽減することにもつながります。遅延の小さい音響システムを ルタイム性能に対する要求が着々と高まっています。そうした オーディオ用DSPではなくSoCに実装しようとすると、数多く ニーズに適切に対応するためには、戦略的な考え方を採り入れな の課題に直面することになります。遅延、スケーラビリティ、アッ ければなりません。大規模なSoC（System on Chip）が十分な プグレード性、アルゴリズム、ハードウェア・アクセラレーショ 性能を提供していることを考えると、追加で必要になった音響処 ン、カスタマ・サポートなどが主な課題です。以下では、それぞ 理もSoCで対応したくなるかもしれません。しかし、その際には、 れについて順に検討していきます。 遅延と時間確定性（determinism）について慎重に検討する必要 があります。これらは、リアルタイム・システムにおいて大きな 遅延 問題につながりやすい重要な要素であることを理解しておかなけ リアルタイム音響処理を実現するシステムでは、遅延が重要な問 ればなりません。リアルタイム音響システムを開発する際には、 題になります。プロセッサがリアルタイムのデータの移動や計算 SoCとオーディオ用デジタル・シグナル・プロセッサ（DSP）の の要求に対応できない場合には、許容できないレベルで音声の途 うち、どちらで対応するのか慎重に検討を行う必要があります。 切れが生じる可能性があります。 本稿では、その選択で失敗しないために考察すべきいくつかの事 柄について説明します。 通常、SoCに集積されるSRAMの容量は大きくありません。その ため、ローカル・メモリへのアクセスのほとんどは、キャッシュ 遅延の小さい音響システムは、様々なアプリケーションで使用さ に依存することになります。その結果、コードやデータはデタミ れています。車載分野を例にとると、パーソナル・オーディオ・ ニスティックに使用されるわけではなくなり、処理に伴う遅延が ゾーン、RNC（Road Noise Cancellation）、車内通信システム 増加することになります。ANCなどのリアルタイム・アプリケー などで使われています。いずれのアプリケーションにおいても、 ションでは、それだけで必要な処理を実現できなくなる可能性が 遅延を抑えることが非常に重要です。 あります。SoCは、マルチタスクの重い負荷を管理する非リアル 周知のとおり、自動車の分野には、車両の電動化という大きなト タイムOSを実行します。このことから、システムの非デタミニ レンドが存在します。それに伴い、RNCの重要性はより増してい スティックな動作が増加し、マルチタスク環境で比較的複雑な音 ます。電気自動車には、騒音を発する燃焼エンジンが存在しませ 響処理をサポートすることが困難になります。 VISIT ANALOG.COM/JP

図1は、SoCでリアルタイム・オーディオ処理を実行している場 スケーラビリティ 合の負荷の推移を表したものです。これを見ると、SoCのタスク SoCを使用した場合の遅延は、ノイズ制御などのアプリケーショ の中でも優先順位の高い処理を実行している際には、CPUの負 ンでも問題になります。ただ、音響処理に関するSoCの重要な欠 荷にスパイクが生じています。これらのスパイクは、メディア・ 点はもう1つあります。それはスケーラビリティです。SoCによっ レンダリング、ブラウジング、アプリケーションの実行など、 て、多くの異なるサブシステムを伴う大規模なシステム（車載 SoCを中心としたアクティビティに伴って生じる可能性がありま ヘッドエンド・ユニットやクラスタ）を制御するケースを考えま す。CPUの負荷が100%を超えるレベルのスパイクが発生する す。その場合、SoCについては、ローエンドのオーディオからハ と、SoCはリアルタイム動作を実現できなくなり、音声の途切れ イエンドのオーディオまでの異なるニーズに対し、スケーリング が生じます。 によって簡単に応じることはできません。なぜなら、各サブシス テムのコンポーネントにおいて、スケーラビリティに対するニー フルOS：ハイ ズは常に競合し、SoC全体の利用率についてのトレードオフが必 120 要になるからです。例えば、ヘッドエンドに適用されるSoCがリ 110 最大のスパイク モートのチューナに接続されていたとします。そのチューナは、 100 約115%の負荷 車種に応じて数チャンネルから多数のチャンネルまでスケーリン 90 グしなければならないとしましょう。その場合、チャンネルの構 80 成ごとに先述したリアルタイム性に関する懸念が増大することに 70 なります。なぜなら、SoCの制御下に機能が追加されるたびに、 60 SoCのリアルタイム動作と、複数の機能に使用されるアーキテク 50 チャの主要なコンポーネントのリソースの利用可能性が変化する 40 からです。そうしたリソースの例としては、メモリ帯域幅、プロ 30 セッサ・コアのサイクル、システムのバス・ファブリックにおけ 20 0 50 100 150 200 250 時間〔秒〕 るアービトレーション・スロットなどが挙げられます。 図1. CPUの瞬時負荷。代表的なSoCが、 上述したように、マルチタスクに対応するSoCに他のサブシス 他のタスクに加えてオーディオ関連のメモリ処理を実行している 場合の様子を表しています1。 テムを接続することについては懸念があります。それ以外に、音 響サブシステム自体にも固有のスケーラビリティの問題がありま 一方、オーディオ用DSPは、信号処理用のパスの全体にわたっ す。例えば、実際のアプリケーションでは、ローエンドからハイ て遅延を小さく抑えられるように設計されています。信号処理 エンドまでのスケーリング（例えば、ANCのアプリケーション 用のパス全体とは、サンプリングされたオーディオ入力からコン でマイクやスピーカのチャンネル数を増やす場合など）が行われ ポジット（オーディオ信号＋アンチノイズ信号など）スピーカ出 るケースがあります。また、基本的なオーディオ信号のデコード 力までのすべてを指します。命令用のL1キャッシュとデータ用 から、ステレオ再生、3Dの仮想化といった高度な機能まで、オー のSRAM（プロセッサ・コアに最も近いシングルサイクル・メモ ディオに対するユーザ体験のスケーリングが行われることもあり リ）は、中間データを外付けのメモリにオフロードすることなく、 ます。そうした要件は、ANCに対応するシステムにおいてリア 多くの処理アルゴリズムをサポートできるレベルの十分な容量を ルタイム処理に関する制約を共有することはありません。しかし、 備えています。また、L1キャッシュ（SRAM）の容量を超過した システムで使用するオーディオ用プロセッサの選択には直接影響 場合には、オンチップのL2キャッシュ（コアから離れているもの を及ぼします。 の、外付けのDRAMと比べればはるかに高速なアクセスが可能） により、中間データの処理用のバッファを提供することができま SoCのコプロセッサとしてオーディオ用DSPを利用するのは、 す。加えて、オーディオ用DSPは、一般的にはリアルタイムOS オーディオに関するスケーラビリティの問題を解決するための完 （RTOS）を実行します。そのため、入力データは新たな入力デー 璧な策です。モジュール式のシステム設計を行えるようになり、 タが到達するまでに処理されて、適切な宛先に送出されます。リ 最適なコストでソリューションを実現可能になります。ほとんど アルタイム動作の最中にデータ・バッファがオーバーフローする 場合、SoCは、より大規模なシステムのリアルタイム音響処理に ことは決してありません。 関するニーズに対して重点を置くことできません。ただ、その処 理を遅延の小さいオーディオ用DSPにオフロードする役割は果た システムを起動する際の実際の遅延（多くの場合、オーディオが せます。またオーディオ用DSPについては、コードの互換性とピ 利用可能になるまでの時間を測定）も重要な指標です。特に車載 ンの互換性に関連する包括的なロードマップにおいて、様々な価 システムでは、起動から一定の時間内に警告音を鳴らす必要があ 格／性能／メモリの製品が提供されています。つまり、システム ります。SoCの場合、通常はデバイス全体にわたりOSの起動を 設計者が所定の製品のレベルに応じてオーディオ性能を最適化す 伴う非常に長い起動シーケンスが存在します。そのため、起動に ることができるだけの高い柔軟性を備えています。 関する要件を満足することが困難または不可能であるケースが少 なくありません。一方、独自のRTOSを実行するスタンドアロン のオーディオ用DSPは、他のシステムの無関係な優先順位の影 響を受けることなく、高速な起動に向けて最適化することができ ます。そのため、オーディオを利用できるようになるまでの時間 については、容易に要件を満たすことが可能です。 2 リアルタイム音響処理を 成功に導く方法 CPUの負荷〔%〕

システム制御 SHARC+ ペリフェラル 2×2 高精度クロック 14 セキュリティと保護 最高1000MHzの ・ジェネレータ DAI SRU GPIO システム保護ユニット（SPU） 浮動小数点演算 ASRC Full DSP 8ペア SPORT 14 障害管理ユニット（FMU） （0～7） DAI GPIO システム・メモリ S/PDIF Rx/Tx 2×1 SRU 保護ユニット（SMPU） 6× I²C デュアルCRC（DMAメモリ搭載） 1×SPI + 2×クワッドSPI + ウォッチドッグ・タイマー 1×オクタルSPI OTP L1 SRAM（パリティ付き） 3×UART 40 5 Mb (640 kB) 2×Link Port GPIO SRAM／キャッシュ プログラム・フロー MediaLB（MLB） 3ピン システム・イベント・ コントローラ（SEC） 10×汎用タイマー（PWM搭載） 1×カウンタ（CNT） トリガ・ルーティング ・ユニット（TRU） クロック、リセット、電源 システム・クロスバーとDMAサブシステム クロック・ジェネレータ ・ユニット（CGU） リセット制御ユニット（RCU） ダイナミック・パワー・ マネジメント（DPM） L3メモリ システム システム・ L2メモリ アクセラレーション デバッグ・ユニット DDR3 (L) 1MBのL2 SRAM DSP機能 インターフェース Arm® CoreSight （ECC付き） 高性能の BGA品のみ FIR/IIR システム・ウォッチポイント L2ブートROM セキュリティ ・ユニット（SWU） AES-256/SHA-256/ECDSA 16ビットの with PKA/PKT Eng. TRNG データ スケーラブル／高性能なオーディオ用のシングルコアDSP 400MHz～1GHzのスケーラビリティを備えた シングルコアSHARC+の性能 パッケージ スケーラブルなオンチップSRAM（最大1.6MB） 品番 速度グレード オンチップSRAM DDR3/L （Tjunctionは125℃） 1GHz ADSP-21569W 1MB L2 800MHz 400ボールの BGA 640kB 800MHz あり 17mm×17m m ADSP-21567W L1 512kB L2 （0.8mmピッチ） 600MHz ADSP-21566W 400MHz 256kB L2 1GHz ADSP-21565W 1MB L2 800MHz 120ピ ンの 800MHz 640kB なし LQFP-E P ADSP-21563W L1 512kB L2 14mm×14mm 600MHz ADSP-21562W 400MHz 256kB L2 図2. スケーラビリティの高い オーディオ・プロセッサ「ADSP-2156x」 アップグレード性 て言えば、SoCに他の制御領域の機能が追加されると、リアルタ 今日の自動車では、無線によるファームウェアのアップデートが イム性能に予期せぬ影響が及ぶ可能性があります。また、このよ 一般的になっています。アップグレード性は、重要なパッチを発 うな状況の副次的な影響として、すべての動作プレーンにまたが 行したり、新たな機能を提供したりする手段としてますます重要 り、新たな機能のクロステストを実施しなければなりません。そ になっています。ただ、SoCでは、サブシステムの間の依存性が のため、競合するサブシステムの様々な動作モードの間で無数の 高まっていることから、アップグレードによって大きな問題が生 パーミュテーションが発生します。結果として、ソフトウェアの じる可能性があります。そもそも、SoCでは、処理用の複数のス 検証量は、アップグレードのパッケージごとに指数関数的に増加 レッドとデータの移動用のスレッドがリソースについて競合する します。 ことになります。新たな機能が追加された場合、特にアクティビ 見方を変えると、SoCにおけるオーディオ性能の向上は、SoCが ティのピークが突発的に発生している間は、プロセッサの処理能 制御する他のサブシステムの機能のロードマップに加えて、SoC 力やメモリをより多く奪い合うことになります。音響処理につい の利用可能な処理能力に依存するとも言えます。 VISIT ANALOG.COM/JP 3

アルゴリズムの開発、性能 オーディオ処理に適したハードウェア リアルタイム音響処理に使用するアルゴリズムの開発について オーディオ用DSPのプロセッサ・コアは、効率的な並列浮動小数 は、SoCよりもオーディオ用DSPの方が適していることは明ら 点演算とデータ・アクセス向けに特化して設計されています。そ かです。なぜなら、オーディオ用DSPは、そのタスク向けに特化 のアーキテクチャに加え、多くの場合、マルチチャンネルの専用 した製品だからです。スタンドアロンのオーディオ用DSPには、 アクセラレータを搭載しています。そのアクセラレータは、FFT SoCとは大きく異なる点があります。それは、オーディオ用DSP （Fast Fourier Transform）、FIR/IIR（Finite/Infinite Impulse ではグラフィカルな開発環境を利用できることです。つまり、 Response）フィルタ、ASRC（Asynchronous Sample Rate DSP向けのコーディング経験が浅い技術者でも、質の高い音響処 Converter）など、オーディオ分野で使用される一般的な処理に 理を設計に組み込むことができるのです。この種のツールを利用 対応しています。これらを利用すれば、オーディオ用のフィルタ することにより、品質や性能を犠牲にすることなく開発時間を短 処理、サンプリング、周波数領域の変換をCPUコアの外部でリ 縮することが可能になります。結果として、開発コストを削減で アルタイムに実行できます。結果として、コアの実効性能を高め きます。 ることが可能になります。また、最適化されたアーキテクチャと データフロー管理機能により、柔軟性が高くユーザフレンドリな ここでは、グラフィカルなオーディオ開発環境の一例として、ア ® プログラミング・モデルが提供されます。 ナログ・デバイセズのSigmaStudio を紹介します。同ツールに は、直感的に使用できるGUI（Graphical User Interface）が用 オーディオの分野では、チャンネルの数、フィルタ・ストリーム、 意されています（図3）。また、そのGUIに統合された形で信号 サンプル・レートなどが急増しています。そのため、プロセッサ 処理用の様々なアルゴリズムが提供されます。そのため、複雑な には、最大限に構成が可能なピン・インターフェースを備えてい オーディオ信号のフローを容易に作成することができます。加え ることが求められます。つまり、インラインのサンプル・レート て、オーディオ伝送用のA2B（Automotive Audio Bus）の構成 変換、高精度のクロック供給、同期型の高速シリアル・ポートな もグラフィカルに行えます。このように、SigmaStudioはリアル どに対応できるようになっていなければなりません。 タイム音響処理向けのシステム開発に大いに役立ちます。 図3. SigmaStudioのGUI 4 リアルタイム音響処理を 成功に導く方法

DAIのルーティング・ユニット・システム DAI 0 …DRU n–1 DAI 1 … DRU 1 グループAの信号 DRU 0 グループAの信号 グループBの信号 グループBの信号 グループCの信号 グループCの信号 グループDの信号 n:1のMux グループDの信号 グループEの信号 DAIの グループEの信号 ペリフェラル グループFの信号 ペリフェラル セレクト グループFの信号 SPORT: 4 SPORT: 4 S/PDIF Tx/Rx：1 S/PDIF Tx/Rx：1 PCG: 4 PCG: 4 ASRC: 4 ASRC: 4 I/Oピン・ I/Oピン・ バッファ：20 バッファ：20 グループA グループA からFのSRU からFのSRU 図4. DAIのブロック図 それにより、データを効率的にルーティングし、遅延の増加を防 ません。むしろ、その場しのぎでサポートされている機能だと言 ぐことができます。また、外付けのインターフェース用ロジック う方が適切でしょう。 回路が不要になります。アナログ・デバイセズのSHARC®ファミ オーディオ用DSPを採用した場合、複雑な音響システムを開発 リの場合、図4に示すデジタル・オーディオ・インターフェース するための非常に強力なエコシステムを活用できます。例えば、 （DAI：Digital Audio Interface）を利用できます。 最適化されたアルゴリズムのライブラリや、デバイス・ドライ バ、RTOS、使いやすい開発ツールなどを利用可能です。また、 カスタマ・サポート 製品を市場に投入するまでの時間を短縮するためのオーディオ用 組み込みプロセッサを採用して開発を行う場合には見落としがち リファレンス・プラットフォームなども提供されています。図5 なことがあります。それはカスタマ・サポートです。 に示したのは、アナログ・デバイセズのSHARCオーディオ・モ SoCのベンダーは、自社のDSP統合製品で音響アルゴリズムを ジュールです。このようなプラットフォームは、SoCの分野では 実行することを推奨しています。しかし、それにはいくつかマイ 珍しいかもしれません。しかし、スタンドアロンのオーディオ用 ナスの側面があります。まず、SoCの通常のアプリケーション開 DSPの分野では、ごく一般的に提供されています。 発では、音響に関する専門知識は必要とされません。そのため、 ベンダーからサポートを得ようとしても、一筋縄ではいかないこ とがあります。つまり、SoCが内蔵するDSPを使用して独自の 音響アルゴリズムを開発しようとした場合、期待するほどのカス タマ・サポートは得られにくいということです。ベンダーは標準 的なアルゴリズムしか提供していないこともあれば、音響アルゴ リズムをSoCの1つまたは複数のコアに移植するだけで多額の NRE（Non-Recurring Engineering）を請求することもあります。 ベンダーが完成度の高い低遅延のフレームワーク・ソフトウェア を提供していない場合、成功裏に開発を完了できる保証はありま せん。また、SoCをベースとして音響処理を開発する場合には、 サードパーティのエコシステムの脆弱さに悩まされることになる でしょう。SoCの世界では、音響処理は中心的なテーマではあり 図5. SHARCオーディオ・モジュールの外観 VISIT ANALOG.COM/JP 5

リアルタイム音響処理を実現するシステムを設計する際には、リ ソースについて慎重に検討を行い、戦略的な計画を立てる必要が 著者について あります。マルチタスクに対応するSoCの残った処理能力を割 David Katz（david.katz@analog.com）は、アナログ・ り当てるだけでは不十分であることは明らかです。ぜひ、遅延の デバイセズで車載向けインフォテインメント・システム 小さい処理を実現できるよう最適化されたスタンドアロンのオー のアーキテクチャを担当するディレクタです。30年にわ ディオ用DSPの採用をご検討ください。そうすれば、堅牢性を高 たり、アナログ、デジタル、組み込みシステムの設計に携 め、開発時間を短縮できることが可能になります。また、将来の わってきました。世界に向けて、組み込み処理に関する記 ニーズと性能レベルに対応できる最適なスケーラビリティが得ら 事を100本近く執筆。同分野については、いくつかの学会 れるはずです。 論文も発表しています。以前は、Motorolaのシニア設計 エンジニアとしてケーブル・モデムやFAに関する業務に携 参考資料 わっていました。コーネル大学で電気工学の学士号と修士 1 号を取得しています。 Paul Beckmann「Multicore SOC Processors: Performance, Analysis, and Optimization（マルチコアのSoCプロセッサ： 性能、分析、最適化）」2017 AES International Conference on Automotive Audio、2017年8月 EngineerZone® オンライン・サポート・コミュニティ アナログ・デバイセズのオンライン・サポート・コミュ ニティに参加すれば、各種の分野を専門とする技術者と の連携を図ることができます。難易度の高い設計上の問 題について問い合わせを行ったり、FAQを参照したり、 ディスカッションに参加したりすることが可能です。 Visit ez.analog.com ＊英語版技術記事はこちらよりご覧いただけます。 VISIT A N A L O G . C O M / J P お住いの地域の本社、販売代理店などの情報は、analog. ©2021 Analog Devices, Inc. All rights reserved. com/jp/contact をご覧ください。 本紙記載の商標および登録商標は、各社の所有に属します。 Ahead of What’s Possibleはアナログ・デバイセズの商標です。 オンラインサポートコミュニティEngineerZoneでは、アナ ログ・デバイセズのエキスパートへの質問、FAQの閲覧がで きます。 TA22758-4/21