音声信号処理の勉強ノート - 2. リアルタイム
リアルタイムDSPとは、入力された信号を「遅延が許容できない」状況で、ほぼ即座に処理し、結果を出力するシステムを指します。リアルタイム処理では、音声信号やオーディオエフェクトが遅延なく適用され、ユーザーに対して違和感のない応答が求められます。
リアルタイムと非リアルタイムの違い
リアルタイムシステムと非リアルタイムシステムの主な違いは、処理の遅延（レイテンシー）です。
非リアルタイムシステム
- 定義: 遅延が許容されるシステム。処理に時間がかかっても結果を得られれば問題ない場合に使用されます。
- 例: オーディオ編集ソフト（DAW）でのバッチ処理やオフラインでの音声解析、音声ファイルのエンコーディングなど。これらのシステムでは、処理速度よりも精度や複雑な処理の方が優先されます。処理に数秒、数分かかることがあっても大きな問題にはなりません。
リアルタイムシステム
- 定義: 信号が処理される際に、特定の時間制約内で結果を出力する必要があるシステム。
- 例: ライブ音声処理、オンライン通話、楽器演奏のエフェクト、ゲームのサウンドエンジンなど。これらでは、信号がほぼ即座に処理される必要があり、遅延が発生すると音声のタイミングがずれてしまい、ユーザーが違和感を覚えます。
- 制約: ハードウェアやソフトウェアの処理能力に限界があり、リアルタイムでの処理は遅延を最小限に抑えつつ、一定の計算量の中で効率よく処理する必要があります。
ハードリアルタイムシステムとソフトリアルタイムシステム
リアルタイムシステムは、処理結果を決まった時間内に出力することが求められますが、その時間制約の厳しさによって、システムはハードリアルタイムとソフトリアルタイムの2つに分類されます。
ハードリアルタイムシステム
ハードリアルタイムシステムは、厳格な時間制約が課せられているシステムであり、指定された時間内に処理が完了しなければ重大な障害が発生する可能性があるシステムです。
例: 航空機の制御システム、医療機器
ソフトリアルタイムシステム
ソフトリアルタイムシステムは、時間制約があるものの、デッドラインを厳守する必要がないシステムです。遅延が発生しても結果に多少の影響を与えるものの、システム全体が失敗することはありません。
例: 音楽ストリーミングサービスやビデオ会議、ビデオゲーム
実装とプログラミングの基本
ここまで学んだ一般的な概念や技術的な基礎を基に、実際のプログラムやシステム設計にどのように応用するかを掘り下げていきます。
オペレーティングシステム
リアルタイムDSPを実現する際には、使用するオペレーティングシステム（OS）が重要な役割を果たします。DSPを行う際には、一般的なOSやリアルタイムOS、さらにはOSを使用しない「ベアメタル」アプローチが選択肢として考えられます。
一般目的オペレーティングシステム（General Purpose Operating System, GP-OS）
一般目的オペレーティングシステムは、コンピュータやデバイス上でさまざまなアプリケーションを実行するための汎用的なOSです。GP-OSは、ユーザー向けの多用途のタスク管理を目的としており、リアルタイム性は必ずしも最優先ではありません。
リアルタイムオペレーティングシステム（Real-Time Operating System, RTOS）
リアルタイムオペレーティングシステムは、タスクの実行タイミングに厳密な制約が求められるシステム向けに設計されています。RTOSは、ハードリアルタイムおよびソフトリアルタイムのアプリケーションに適したタイムクリティカルな処理を保証します。
ベアメタル（No Operating System / Bare Metal）
ベアメタルとは、OSを使用せずに、直接ハードウェアを操作するアプローチです。プログラムが直接ハードウェアリソース（CPU、メモリ、入出力デバイスなど）にアクセスするため、最も制約のないリアルタイム処理が可能です。
プログラミング言語
リアルタイムDSPを実装する際に、どのプログラミング言語を選ぶかは、プロジェクトの特性に大きく影響します。特にリアルタイム処理では、次のような基準が重要です。
パフォーマンス
リアルタイムDSPでは、信号を瞬時に処理する必要があるため、言語のパフォーマンスが重要です。特に、低レイテンシーでの処理が求められるゆえ、言語自体の実行速度が速く、メモリ管理やCPUの効率的な利用が可能であることが必要です。
メモリ管理
リアルタイム処理では、メモリ管理が予測可能であることが非常に重要です。ガベージコレクションが突然動作してパフォーマンスを低下させるような言語は、リアルタイム処理には不向きです。手動またはコンパイル時にメモリ管理を明示的に制御できる言語が好まれます。
ハードウェアへのアクセス
リアルタイムDSPは、しばしば特定のハードウェアやDSPチップ上で動作するため、言語がそのハードウェアに直接アクセスできるかが重要です。低レベルでのハードウェア制御が可能な言語は、リアルタイムシステムにおいて有利です。
リアルタイムDSPでよく使われる言語
- C/C++
- Python（C拡張と併用）
- Rust
コーディングの際に注意すべきポイント
リアルタイムDSPシステムの開発では、特にオーディオコールバックで動作するコードの書き方に細心の注意が必要です。オーディオコールバックは、入力されたオーディオ信号を処理し、即座に出力する役割を担っており、処理の遅延が直接的に音の品質に影響を与えます。以下は、リアルタイムDSPプログラムを書く際に特に注意すべきポイントです。
オーディオコールバックとは
リアルタイムDSPにおけるオーディオコールバックは、入力された音声データをリアルタイムで処理し、瞬時に出力するための重要な仕組みです。このコールバックは、一定のバッファサイズでデータを受け取り、処理を行います。例えば、オーディオコールバックはミリ秒単位で定期的に呼び出され、遅延なく音声処理が行われる必要があります。
オーディオコールバックのタイムスケールは、非常に短く、通常1フレームごとの処理は数ミリ秒で完了する必要があります。例として、以下のリンクから、Androidデバイスがどのようなタイムスケールでオーディオコールバックを処理しているか確認できます。
-
オーディオコールバックは待たせない
オーディオコールバックはリアルタイムで実行されるため、待機や遅延を発生させるコードを実行してはいけません。コールバック内でスレッドの同期や待機操作（sleepやwaitなど）を行うと、処理が止まってしまい、音声が途切れる原因になります。 -
オーディオのドロップアウトを引き起こさない
オーディオドロップアウトは、信号処理が遅れ、バッファが空になったり、処理が追いつかなくなる現象です。これが発生すると、再生される音声が途切れたり、不自然なノイズが発生します。 -
オーディオコールバック内ではロックフリーコードのみを実行する
ロック（mutexなど）を使ったスレッドの同期操作は、予測不能な待機時間を発生させることがあります。オーディオコールバックは、一定のサイクルで定期的に実行されるため、ロックによる待ち時間があると、オーディオのドロップアウトが発生する可能性があります。 -
実行時間が予測できない処理を避ける
リアルタイムオーディオ処理では、処理にかかる時間が予測不能な操作を避ける必要があります。例えば、ループの中で処理がどれだけかかるか予測できない場合や、外部からの遅延が発生するような操作は、コールバックの実行時間に影響を与える可能性があります。
- オーディオスレッドでのメモリの(デ)アロケーションを避ける
- オーディオスレッドでのI/O処理を避ける
- 最悪のケースの動作が不安定なアルゴリズムを避ける
まとめと次のステップ
この記事では、リアルタイムDSPの実装において重要なポイントを整理しました: リアルタイムオーディオ処理では、タイミングやレイテンシーの管理が非常に重要であり、コールバック内での処理が確実に予測できる必要があります。また、メモリ管理やI/O処理も慎重に行うことが求められます。
次のステップでは、リアルタイムDSPシステムの実装に向けて、一般目的オペレーティングシステムを使用することにします。これらのOSは開発環境が充実しており、DSPに必要なツールやライブラリも豊富に揃っています。加えて、プログラミング言語としてRustを選択します。Rustはパフォーマンスとメモリ安全性を両立しており、リアルタイムシステムでの安定性を確保しながら効率的に実装を行うのに最適です。これから、Rustを使用した他の人の例を参考に、学習と実装の足がかりとしていきます。