🔇

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

2021/01/06に公開約3,600字

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

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

2017年の議論

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

https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/

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

https://robert.ocallahan.org/2017/09/some-opinions-on-history-of-web-audio.html

何が良くないのか

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

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

要因を考える

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

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

http://web.archive.org/web/20101101110617/http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html

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

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

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

https://www.w3.org/TR/webaudio-usecases/

目標設定自体は正しく、ビデオカンファレンスや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を自然に拡張している。

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によるオーディオ処理の抽象化に疑問を投げかけていると思う。

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

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

Discussion

ログインするとコメントできます