🔇

WebAudioは何故あんな事になっているのか

2021/01/06に公開

webaudio

idea

最近 Node.js でEmscriptenのアプリを動かそうとしているけど、真面目にやっていないものの一つにWebAudioがある。

WebGL1はまぁ頑張ってFFIバインディングを用意したんだけど、WebAudioを真面目に実装すべきかをちょっと考え中。

2017年の議論

WebAudioの不必要な複雑さはHackernewsで盛り上ったことがある。

https://news.ycombinator.com/item?id=15240762 -- リンクされていたblogは↓

策定に関わった(カウンターを出したMozillaの)人のレスポンスもある

何が良くないのか

インタラクティブ音声を再生するという目的のためには、不必要に高機能である。

WebAudioはとても高機能で、シンセサイザやフィルタを駆使してMIDI音源まで実現できる( https://github.com/g200kg/webaudio-tinysynth )。しかし、ここまでの機能を必要としている具体的なユースケースがあるだろうか。

要因を考える

デザイン当時のJavaScriptは遅かったから説

たぶん最大の要因は、当時(2010年 ((このプロポーサルを出した本人は2013年にエディタから降りている)) )のJavaScriptが遅かったことがデザイン判断に影響した点だろう。

この最初のドラフトの段階で、かなりのWebAudioの要素が提案されていることがわかる。これらを2010年当時のJavaScript環境(asm.js以前)で実現するには、固定機能をネイティブコードで持つほかは無かっただろう。

目標設定がおかしかった説

WebAudioには仕様で引いている想定ユースケースがドキュメント化されている。

目標設定自体は正しく、ビデオカンファレンスや3Dゲームは実際のユースケースに叶っている。ただ、WebAudioが想定通りの貢献をできているかは何とも言えない。

2.1 Video Chat Application

ユースケース文書では、

Mixing and spatialization of several sound sources

Controlling the gain (mute and volume control) of several audio sources

Filtering (EQ, voice enhancement)

Modifying the pitch and speed of sound sources

などの加工が挙げられているが、現実にはオーディオどころかビデオの加工までWebAssembly( mediapipe 等)が現実的なラインに来てしまっている。

2.2 3D game with music and convincing sound effects

これは実際にはWebAudioの世界には来ていない。

Emscriptenは3DミキサーとしてWebAudioを使用しているものの、エフェクト類は一切実装していない。

Unityは独自にWebAudioを使用したオーディオ再生を実装しているが、Emscriptenとの機能差はAAC圧縮オーディオを3D panningしている点だけで、やはりエフェクト類は一切実装していない。

例外 : 各プラットフォーム向けの3D Audio APIであるResonance Audio SDK はWebAudioの畳み込みフィルタを活用して聴感を向上させるとともに、WebAudioのAPIを自然に拡張している。

デモ: https://cdn.rawgit.com/resonance-audio/resonance-audio-web-sdk/master/examples/index.html
リポジトリ: https://github.com/resonance-audio/resonance-audio-web-sdk

OpenMAXやOpenALがあまり成功しなかったから説

WebGLの重要なユースケースとして、OpenGL ESで書かれたアプリケーションをほぼそのままWebGLで動作させられる点がある。

しかし、WebAudioには、それに対応するだけのメジャーなオーディオAPIがPC側になく、ゼロからアプリケーションを募ることになってしまっている。このため、WebAudioのデザインを正当化できる理由に乏しいのではないだろうか。

EmscriptenはOpenALをWebAudio上に構築している。オーディオAPIとしてのOpenALはAppleがかなり初期からサポートしている等普及はしているものの、OpenAL自体にはあまり大きな進展が無い状態となっている。

例えば、3Dオーディオの重要なコンシューマであるVR市場に対応するだけの機能性をOpenALは備えていない。

Khronosの OpenMAX はWebAudioにかなり近い構成のAPIで、かつ、DSPの抽象化レイヤとしてはそれなりのシェアがあった。例えば、RaspberryPiはOpenMAXの実装を持っているし、AndroidのCodec抽象化レイヤとしても採用されていた。

このため、例えばフィルタ処理等をOpenMAX側に逃がすといった形でWebAudio APIをオフロードすることがもし可能であれば、WebAudioを省電力で実行するといったことに価値があったかもしれない。(が、現実のWebAudioはそのようなオフロードを想定した構成にはなっていない。)

オープンスタンダードの意義と今後

実はWebAudioはオーディオAPIのオープンスタンダードとしては唯一生き残っている存在と言える。

OpenALはSoundblasterやnVidia nForceのDSP抽象化として広く採用されたものの、現役でハードウェアアクセラレーションを提供しているデバイスは存在しない。ハードウェアアクセラレーションを想定したオーディオAPIで現役のものとしてはWindows Sonic等があるが、オープンスタンダードではない。

OpenMAXはKhronos自身によってInactive Standardに分類されている。

この2つのAPIの現実がWebAudioによるオーディオ処理の抽象化に疑問を投げかけていると思う。

オーディオ処理に高度な抽象化APIが必要だった時代は終わった 。CPUが十分にパワフルになったので、オフロードエンジンのための高度な抽象化APIが要らなくなった。
市場のプレイヤが減少しオープンスタンダードを保てなくなった 。AndroidはOpenMAXから自身のHALに置き換えている。モバイルプラットフォームの選択肢が劇的に減りつつあるため、標準に対応していることではなく特定のプラットフォームをサポートしていることがチップセットのウリになっている。

まぁ現状でも音鳴るから良いじゃんと言われればそれまでだけど。