2024年のオーディオアプリケーション開発技術の動向に関する私的見解 (2)

昨日の続き。今日は「現代的な課題だけど実装がやや追いついていない技術」編。

MIDI 2.0のadoption

MIDI 2.0のサポートは、段階的に追加されているものの、その歩みは緩慢だ。

MIDI 2.0は2023年に大きなアップデートがあり、そのタイミングでLinux ALSAにはUMPサポートが追加された。この時点でプラットフォームAPIとしてMIDI 2.0を十分にサポートしていなかった主要OSはWindowsとAndroidのみだった（ChromeOSは…Web以外で音楽やる気ないし主要OSから外してもいいだろう）。今年になってAndroid 15が仮想MIDI 2.0デバイスをサポートするようになって、残るはWindowsだけになった。先に良いニュースを書くと、Windows MIDI Service (WindowsのMIDI 2.0サポート) の開発はかなり可視化されている。悪いニュースは、その開発は当初の見積もりよりは遅れていて（当初は2023年内に出る予定だった）、2024年内のうちに出したいという見込みまでずれ込んだということだ。もっとも3月のPreview 5リリースの時点でmoving into productionと言っていて、これはもう少し早まる可能性も十分にある。

プラットフォームのMIDIアクセスAPIを使用するライブラリの中には、たとえばceltera/libremidiのようにWindows MIDI Serviceの正式リリースを待たずにリリースしているものもあるけど、JUCEのようにMIDI 2.0サポートを（追加しては取り下げたりしていたものの結局は）MSのリリースが出るまで出さないと宣言する…みたいなスタンスのほうが多そうだ。

JUCEがMIDI 2.0をサポートしないうちは、Tracktion WaveformにもMIDI 2.0サポートは来ない。DAWのMIDI 2.0サポートを眺めてみると、現状そこまで手を出せているのはAppleとSteinbergくらいで、他のDAWはまだサポート表明もしていない。DAW上のシーケンスから各プラグインフォーマットのイベントに変換するのは難しくない（LV2の場合はAtomへの何らかのマッピングポリシーが必要そうだが）。しかしDAWのトラックではすでにプラグインのパラメーター等が32bit（や64bit）で打ち込まれていたり、MPEがサポートされていたりするわけで、MIDI 2.0サポートは主に入力デバイス対応とエクスポート機能くらいになるだろう。エクスポートのフォーマットにしても、SMF2 container formatはまだ策定が進んでいないのが現状だ。

プラグインSDK側でも、JUCEのAudioProcessorのようなAPIでMidiMessagesの代わりにUMPを処理できるような関数が追加される必要もある。これは外部入力を伴わない、プラグインフォーマットのAPIとの調整のみで足りるのだから、Windows MIDI Serviceの完成を待つ必要は全然無い。着手している様子もないのは、単にJUCEチームの中でMIDI 2.0サポートの優先度が低いということだろう。

まだまだ足りないものだらけだが、USB MIDI 2.0のプロトコルが先に仕様としてファイナライズされている状況はある意味十分よくて、ハードウェアベンダーはUSBプロトコルのレベルでは後方互換性を期待して製品をリリースできるということだ。MIDI-CIのサポートは、去年ようやく仕様が固まったプログラムリストやコントロールリスト、今年ようやく仕様が固まったMPE Profileみたいなのもあって、まだDAWでサポートされるまでは時間がかかるだろうけど（そもそもMIDI 2.0対応プラグインが登場してMIDI-CIのやり取りが実現できる必要がある）、そこは大した問題じゃないし、ソフトウェアレベルで解決させればよい。

プロセス分離モデルへの対応

VSTもAUv2もCLAPも、プラグインを動的ライブラリとしてロードする処理モデルになっている。このモデルはAUv3では通用しない。AUv3プラグインは、App Storeで配布されるDAWアプリケーションのサンドボックスでロードできるような動的ライブラリではなく、App Extensionの仕組みに則ってロードされるし、プラグインもApp Extensionとして構築することになる。それぞれのアプリケーションプロセスがコンテナライズされるので、オーディオプラグインフォーマットの規約に基づいて定義された関数を動的ライブラリから動的に引っ張ってきて呼び出す、みたいな雑なことはできないので、IPCのような手段に頼ることになる。

AUv3は、去年Logic Pro for iPadがリリースされた時にやや機運が盛り上がった界隈もあるけど、少なくともMac App Storeのほうではそれほどアプリケーションが増えていないようだ。AUv3のプロセス分離モデル自体は新しいトピックではないしだいぶ前から書いているので（まあ今よりだいぶ理解不足の頃に書いていたものではあるけど）、改めて書くことは多くない。

プロセス分離モデルは、AUv3に限られたものではない。Linuxでディストリビューションの違いに悩まされずにアプリケーション パッケージを配布しようとしてFlatpakやSnapを選択すると、これらのプラットフォームに類似する問題に直面することになる。これらのアプリケーション パッケージでは、デフォルトではアクセスできるファイルシステムやプロセスの範囲は限られている。FlatHubにはArdour, QTractor, Zrythm, Reaper, Waveform11などいくつかのDAWが商用・非商用を問わず登録されているが、これらはHOMEディレクトリへのアクセスを明示的に許可されたものでなければ、~/.vst3や/.lv2にアクセスできない。なので、大抵のDAWのFlatpakではパッケージの.ymlのfinish-argsに--filesystem=homeや--filesystem=host（これはだいぶ広い例）が指定されている。

サンドボックス機構で影響を受けるのはアプリケーションだけではない。オーディオシステムは複数のプロセスで成り立っていて、PulseAudioのようなオーディオサーバはユーザーランドで動作するため、コンテナ化の影響をもろに受ける（なので、pulseaudioとオーディオのやり取りが必要になるDAWのパッケージでは、--socket=pulseaudioもサンドボックスの例外的アクセス許可に追加される）。結局のところ、FlatpakやSnapでプロセス分離モデルといいつつ、まだまだ抜け道を使ってアクセスするのが一般的な状況だ。

一方で、サンドボックス機構を最初から想定して設計されたPipeWireのようなオーディオシステムもある。PipeWireは昨年11月に1.0がリリースされた。PipeWireを使用するオーディオアプリケーションは、PipeWireクライアントAPIを経由してPipeWireサーバにアクセスする。PipeWireサーバはコンテナの外で動作しており、PipeWireクライアント ライブラリがFlatpakのPortalを経由してサーバに接続するように作られている。PipeWireクライアントとサーバはオーディオデータを共有メモリで受け渡し、制御コマンドはIPCでやり取りする。読み書きは「制御」に含まれない。ストリームの位置情報も別途共有メモリに置く…といった仕組みで、基本的にロックフリーなオーディオ処理を実現している。

PulseAudioはネットワーク オーディオなどを包摂的にサポートする目的で開発されたもので、リアルタイム オーディオ処理を想定して作られた機構ではなかった。そのためArdour開発者らに近いpro audio方面のユーザーからは"not for us"という感じで冷遇され続けてきた。PipeWireはその部分を克服して、JackやPulseAudio互換のAPIも用意していて、新たなオーディオサーバのデフォルトの選択肢として台頭しつつある。

PipeWireでもうひとつ自分が個人的に注目しているのが、MIDIや映像の入力も同様のストリーミングで扱えるところだ。JackにMIDIサポートがあったのだから特に不自然なものではないが、MIDI入出力がオーディオ入出力と別になっていると、sample accurateなMIDI処理ができないAndroid AAudioやVST3のようになってしまうので、先見の明があるといえる。MIDI 2.0のUMPはまだサポートされていないが、APIと設計を見る限り、LV2 Atomに似ていて、MIDI 1.0ストリームの代わりにUMPを流すようにするのはそんなに難しくはなさそうだ。

今日はここまで。といっても(3)が書き上がるのか、いつ書き上がるのかは未定。トレンドとして言及すべき技術はもちろんまだまだいくつかあって、調べて書けるかどうか次第だ。