前回の記事では、実際にUnity内で音を鳴らした場合の、オブジェクト数や2D/3Dの有無による計測を行いました。
今回は、オーディオクリップのLoad TypeやCompression Formatの違いによる比較をしてみたいと思います。
Load Type三種類、Compression Formatは『PCM』『ADPCM』『Vorbis(Quality1)』『Vorbis(Quality100)』の四種類を組み合わせ、合計12パターンの計測を行っています。
なお比較項目が多数のため、今回はテーブルでなくグラフ画像を載せています。
各画像はクリックで拡大表示可能です。
オブジェクト1個の場合
前回の記事と若干被りますが、手始めにオブジェクト1個での各組合せを調べます。
まずCPU使用率のグラフです。横軸は5%を最大値にしています。
どの組み合わせも1%前後とさほど大きな負荷にはなっていません。
Streamingで鳴らした場合だけ、グラフ内オレンジ色のStreamingCPUが表われる特徴がみられますね。
メモリに関しては、横軸25MBを最大としています。
Decompress On Loadの場合に灰色のSample Sound Memoryが表れますね。
黄色のOther Memoryはどの組み合わせでも必ず一定サイズが存在します。
Unityのサウンドが使用しているシステム領域のような感じでしょうか。
オブジェクト100個の場合
まずはCPU使用率です。1個の場合と異なり、横軸の最大値は100%となっています。
おおよその予想通り、Decompress On Load < Compressed In Memory < Streaming の順でCPU使用率が上がりますね。
興味深いのはPCMフォーマットでも結構CPU使用率があることと、VorbisのQuality1のCPU使用率が低い点です。
とはいえ、Quality1の音質はお察しなので使用場面は限られますが……
続いてメモリのグラフです。
Streamingのメモリ使用量がエグい……！
Decompress On LoadとCompressed In Memoryはオブジェクト1個の時とほとんど差がないのですが、Streamingが想像以上にスゴイ結果となりました。
File MemoryとDecode Memoryと同じ量のメモリを二つ確保するため、メモリの使用量も極端に大きくなっています。
オブジェクト2個/3個の場合
気になったので、オブジェクトが2個と3個の場合のメモリ使用量も計測してみました。
赤丸のところに注目です！
グラフではわかりづらいですが、オブジェクトが1個増えるごとにStreaming File MemoryとStreaming Decode Memoryがそれぞれ124KBずつ増えています。
どうやらストリーム再生用のメモリバッファは、オブジェクトの分だけ生成されてしまうものと推測できます。
これが100個のオブジェクトをストリーム再生した際の極端なメモリ増加の原因かと思われます。
おわりに
やみくもにストリーム再生を使うと、大量生成した再生用オブジェクトによってCPUとメモリ両方に大きな負担がかかってしまいます。
ここまでの内容だとストリーム再生のメリットが少ない印象になりがちですが、BGMのようなメモリに置くのが難しいほどの大きいデータサイズのサウンドを鳴らしたいときに用いるのが効果的です。
では、Load TypeとCompression Formatの組み合わせはどのように使い分けるのが適切なのでしょうか？
次回以降は、効果的な運用例を解説したいと思います。
