2024年のオーディオアプリケーション開発技術の動向に関する私的見解 (3)
Part 1やPart 2と同様に、ホントはもう1項目くらい書いてからpart 3としたかったのだけど、他の作業が忙しくて全然進まないのでとりあえず1つだけ。
AI技術とAIデータモデルランタイムの組み込み
AI技術がホットな領域なのは言うまでもないだろう。DAWは多数の肉体労働と専門知を要するスキル作業に満ちていて、さまざまな領域でAIツールがわれわれの作業を肩代わりする余地がある。自分はAI系アプリ開発者ではないので、あまり包括的な話を書きたい立ち位置にはない。もう少しオーディオアプリ開発者らしいコード寄りの話だけ言及したい。とはいえ前提として技術の概要は少し言及しておこう。
SunoやUdioのような自動作曲ツールは、出力された音楽に対して詳細な修正を詰めることを考えることすら無い人にとっては有用かもしれないが、そうでない限りは入力の調整はテキストプロンプト頼みになってしまう。AIを人間のクリエイティビティの補助ツールとして使いたい人向けの機能ではない。人間が創作的に介入するには、生成された楽曲をいちどパートごとに音源分離して、さらにピッチ検出などでMIDIイベント等に変換する必要がある。
この3つの過程のいずれもAI技術が関与する余地があり、実装も数年前から存在している。もっとも、現役で使われている技術で進化し続けているのは自動作曲のみかもしれない。「かもしれない」というのは、（筆者がそんなに日頃から興味がないということもあるけど）自分があんまし使わないDJソフトとかWeb DAWみたいなやつも、このテの機能をサポートしているからだ。ただ、音源分離に関して見つかる実装はspleeterとdemucs以外はほぼボーカル分離のものだけだし、ピッチ検出はみんなbasic-pitchで済ませているという印象がある。もっとも、sony/timbre-trapみたいな研究開発フェーズっぽいリポジトリも探せば出てくるので、単に普及しているかどうかの問題かもしれない。
ローカルで動作するアプリケーションの場合、学習データモデルを環境に合わせて実行するランタイム（tensorflow | tflite、ONNXRuntimeなど）とモデルデータセットをアプリケーションにバンドルする必要がある。ランタイムはネイティブコードでビルドされていて高級言語のフロントエンドがロードと実行のエントリポイントをもつ、というのが一般的なランタイムであろうが、オーディオアプリケーションの場合、多くはC++でロジックが実装されているので、C++のネイティブランタイムをそのまま組み込む事が多いだろう。
inferenceまでリアルタイムスレッドで呼び出したい場合は、ランタイムがrealtime safeなコードでアロケーションフリー、ロックフリーで実装されている必要がある。tensorflowもtfliteもonnxruntimeも、われわれの世界でいうところのhard RT safetyの実現は技術要件ではないので、RT専用の実装が必要になる。これを実現しているRTNeuralのようなプロジェクトもあり、RTNeuralの開発者自身が作っているギターアンプモデルのプラグインBYODや、学習モデルに基づいてギターエフェクターを実装するGuitarMLのようなプロジェクトは、このRTNeuralを利用している。最新のGuitarixはGuitarMLの成果も取り込んだりしている。
RTNeuralがやっていることはonnx(runtime)やtensorflow | tfliteがやっていることと近い低レベルで、独自モデルのIR（演算子?）を規定してxsimdやEigen（あと標準C++）をバックエンドとして使用して実装している。もっともこれらの高度なランタイムみたいに環境に合わせてリソース（CPUとかGPUとかTPUとか）を使い分けるみたいな実装にはなっていない（はず）。
ちなみに、オーディオプラグインだから何でもリアルタイムスレッドで処理しなければいけない、なんてことはない。ファイルをストリーミングロードしながらリアルタイムのオーディオスレッドとデータを受け渡しするような処理を、AI推測などの出力の生成に置き換えて考えれば、non-RTスレッドでAI処理を回せば十分ということも多いだろう。たとえばNeuralNoteはBasicPitchCNNをRTNeuralでリアルタイムに処理しつつ、その後の処理はONNXRuntimeに非リアルタイムでやらせている。ADC23でリアルタイムで音色変換を実現するプラグインScycloneの開発者がこのアプローチで実装する場合のやり方を解説している（18:00あたりから）:
Discussion