Unity
audio
Adx2
Wwise
FMOD

Unityでサウンドエンジン(ADX2, Wwise, FMOD)を扱う際におさえたい事

はじめに

本文書は、Unityでサウンドまわりを実装する際に各種(ADX2, Wwise, FMOD)を採用するさいに検討したい事と、実装する際に懸念すべき事についての私見です。定性的な部分が多いので定量的な情報をお持ちであればご指摘いただけると幸いです。というか情報がもっとほしい。

結論

はじめに結論をのべておくと、「ほとんどの場合Unityならサウンドエンジンいらない」そして「ある程度したい演出があって楽にやりたいならADX2」「WWiseはつかうならちゃんと使いこなさないと損」「FMODは使うと楽しいけど情報はすくない」「どれを使うにしても発音数をなにも考えずに増やしてはだめ」となります。ある程度使ったことのある人には何をいまさら?というのことをこれから長々と書きます。

環境

  • MacBook Air (11-inch, Early 2015) OSX 10.12.6
  • Unity 2017.3.f3
  • ADX2 Unity Plugin/AssetStore 2.24.00
  • Wwise 2017.2.0.6500
  • FMOD 1.10.02

各エンジンの特徴

世の中にはUnity公式ノンリニアオーディオデモというすごくかっこいいデモがあります。ただ、これの実装はそこそこ大変です。さらにUnity上でオーサリングして調整するとなるとかなり大変そうです。これを各サウンドエンジンで実装することで各エンジンの特徴を再確認しました。

※ページビュー乞食
- ADX2でオーサリング
- ADX2で組み込み
- Wwiseでオーサリング1
- Wwiseでオーサリング2
- Wwiseで組み込み
- FMODでオーサリング
- FMODで組み込み

ざっくり表にすると

項目 オーサリング負荷 組み込み負荷
Unity X X
ADX2
Wwise
FMOD

※便宜上、Unityでもの状態を一番つらい、にしてます。

という感じでした。正直Wwiseのオーサリング負荷はXにしてもいいくらいにつらいものでした。大規模になってくると段々つらさが均されていくのですが、このデモ程度の規模だとちょっとのことのためにメンドくさい部分を直に触ることになるためです。また、オーサリング負荷がADX<FMODなのはUXがわかりやすくてなんとなーくやっても上手くいくからです。実装負荷は正直どれもおなじくらいです。用意されてるコンポーネントもどれも一緒な感じですし。

2018/2/22:お値段の話

聞きかじったお値段の話を書いておきます。
インディーだとだいたいどれもタダです。
今日びの商用クラス1~5億くらいで比較して見ます。

項目 インディー環境 商用価格
Unity - (追加費用なし)
ADX2 LEなら0,AssetStore版なら$100 $28,000~56,000
Wwise $150K規模まで0 $900(+ロイヤリティ)~ 21,000(ロイヤリティなし)
FMOD $500k規模まで0 $5,000~15,000

ちなみにお値段はWwiseとFMODは公式サイトに、ADX2は勤務先に請求がきた金額です。もっと安いよって場合は教えてください。交渉材料にしますんで。

以下にもうすこし詳しい内容を書いておきます。

素Unity

長所

  • 中身はFMOD
  • AudioSource, AudioClipなどのわかりやすいAPI
  • Unity標準装備のプロファイラで最適化できる
  • AssetBundleとも親和性高い
  • 音数がふえたら優先度順に消す、くらいはやってくれる

短所

  • 細かな発音制御しようとするとスクリプト書く必要がある
  • Wavをバージョン管理に含むとプロジェクトが肥大化するのでサブモジュールにしたり、AssetBundle化したりと苦労が多い

ADX2

長所

  • だいたいなんでもできる
  • 日本のゲーム業界のシェアが高い
  • 独自コーデックの圧縮率高い
  • Androidの低遅延再生に優れる(標準40msecに対して15msecくらい)
  • プロファイラーもつかいやすい
  • パッキングシステムも用意されてる

短所

  • 商用でもUnity用に添付されてるサンプルなどは乏しい
  • パッキング用のサンプルはとくに乏しい
  • StreamingAssets前提
  • 機能制限版ではMac用エディタがない
  • 昔からあるがゆえに機能をフルに使ってもらってるのをあまり見ない

Wwise

長所

  • 大体なんでもできる
  • 世界標準なので漁るといろんなプラグインとかある
  • GDCとかで最先端情報を探るとWwiseが前提
  • VR用ソリューションへの対応も早かった
  • 使用者の目的にあわせたレイアウトプリセットが多い
  • 公式チュートリアルがめちゃくちゃ詳しい

短所

  • 日本語情報が少ない
  • 使用目的ごとにレイアウトプリセットを切替えてもなお溢れ出るオーサリングツールの情報量
  • ほかドライバにくらべて常駐メモリ量がやや多い

FMOD

長所

  • オーサリングツールのUXわかりやすい
  • 世界的にはそこそこ採用されてる
  • 発音制御、3Dサウンド、ランダム再生、インタラクティブ...だいたいのことはできる

短所

  • マイナー
  • 日本語情報はめちゃくちゃ少ない
  • 最近までモバイル用がなかったりとやっぱり足が遅い

補足

作業負荷だけでなくエンジニア的にはマシンリソース負荷もきになるところなのでその辺補足しておきます。本当の最適化は各エンジン添付のプロファイラーでおこなうべきですが、公平になるようにUnityプロファイラーから見えるところで比較します。
なお比較は各サウンドエンジンの組み込みで作成したもので、コーデック:ADX2=独自コーデック、FMOD&Wwise=ogg、再生方式いずれもStreamで作成してあります。

ざっくりプロファイラーでみると

Audioプロファイラーでみるとこうなります。

audio_profile.png

全部いっしょ。しってた。

それぞれ独自のPluginで走ってるので当然UnityProfilerからは確認できません。

CPU

もちろんこの程度のデモでは1%たりともCPUをつかわないので比較はあまり意味がありません。

※正直オーディオバッファのfillって1frameないに3frame分つめるくらいで動作しないとプチプチいう世界なので、まともなサウンドエンジンを普通に動かしてるかぎりあんまり負荷ってあがらないんですよね。

ADX2

スクリーンショット 2018-01-28 14.50.20.png
基本はCriAtom.Initializer、Cri.Listener、Cri.Updateがはしる。追加で音源数が増えるとSourceの処理がはいります。

Wwise

スクリーンショット 2018-01-28 14.56.24.png

おなじように音源数によって処理が増えます。

FMOD

スクリーンショット 2018-01-28 14.54.33.png

どれ?

基本的にはどれも音源数によって増える。ということは実は数百〜数千規模になるならあらかじめ刈り取ってあげたほうがいいという中身であろうと思われる。当たり前。

メモリ

 概要

momory_profiler.png

ざっくりみるとADX2とFMODが10MBに対して、FMODが30MB近いように見える。やっぱり若干おおい。

ちなみにWwiseのテクスチャがおおいのは標準プラグイン画面のアイコン

スクリーンショット 2018-01-28 15.26.12.png

はずすの面倒だったんですごめんなさい。そのへんを差し引いてもWwiseは10MB程度は多めに食うようです。

詳細

ADX
スクリーンショット 2018-01-28 17.07.59.png
よくみると結構興味深いです。CriExPlayerが結構多めに食っています。CriAtomPlayerEx=CriAtomSouce.player=音源にかかわるので音源をprefabなどに埋め込んでリクエストとして利用するとこのResourceがおおくなり、またそのGCによって処理が低下することが予測されます。可能ならAudioSourceを使い回すような作りにしていたほうが良い事がわかります。当たり前ですね。

Wwise
wwise_mem.png
そりゃプロファイラ上でメモリ負荷が高くなるよ、という状態です。
Windows用とMac用の便利機能やエディタ用のオブジェクトがたくさんいます。このあたりはReleaseビルドなら消えるので先ほどの数字より若干マシになるはずです。

また、音源用オブジェクトサイズは15kB程度とそこまで大きくなく、Callbakなどのマネージャーが大部分をしめています。これがWwiseをいれると大した事やってないのに多くメモリを食われる理由のようです。もう少し大規模なプロジェクトであればこのあたりの割合が下がるため採用してもよい、という判断になります。

FMOD
スクリーンショット 2018-01-28 17.06.13.png
スクリーンショット 2018-01-28 17.05.55.png
こんどはまともに見るものがありました。イベントのキャッシュは発音イベントのキャッシュで、一回しかリクエストしていないからか、対して大きくありません。Assetモニタではそのかわり250kBとドカッと確保しています。ADX2が細かく確保している分をひとまとまりで確保している感触です。細かいところがみたい。。

要するにどのエンジンでも、音源を何も考えずにふやすとGCでメモリと処理負荷を食われていきそうなのがわかります。

まとめ

デモの完成度などからも、Unity単体でだって色々なことができることはわかります。しかしその実装・調整負荷を下げるためにはサウンドエンジンを採用するという判断が有効です。

その際にADX2は独自コーデックや低遅延といったニッチなニーズに応えてくれ、プロジェクトの規模によってもスケールしやすいため、とりあえずコレと選んでしまってもよいサウンドエンジンです。

Wwiseを採用する場合はコンポーザーとエンジニアががっつり腰をすえてやらないと、コンポーザーの負荷が高く、またマシンリソース的にももったいない結果になっていしまいます。

FMODはUnity環境において正直まだおすすめしにくい状態ですが、UXのわかりやすさからインタラクティブミュージックのモック作成などにはアリです。

参考

日本のモバイルやインディーでもかっこいいサウンド演出が増えていけばいいですね。