Objectメモリ

Objectメモリの使用量は、メモリにロードしたサウンド数やイベント数、そしてゲームオブジェクトの量によって直接、左右されます。これはプロジェクトがサウンドデザインの実装に必要とするオブジェクトすべてのプロパティを含んでいます。また、すべてのゲームオブジェクトとそれらの関連する情報 (ゲームシンク値、位置、向きなど)も含みます。より多くのバンクをロードすると、より多くのメモリアロケーションが必要となります。必要なサイズは、一つのシナリオ、レベル、マップ、ゲームエリアなどで一度に再生する可能性のあるサウンド数に依存します。このアロケーションを減らすには、以下のような心がけが役立ちます:

多数のサウンド構造やEventを入れた大きいサウンドバンクは、いくつかの小さいサウンドバンクに分割する。目安としてAdvanced ProfilerのSoundBanksタブを開けば、それぞれのSoundBankがどれだけのメモリを消費しているかをObject Memory列で確認できます。そして必要に応じてSoundBankを動的にロード、アンロードできます。これらの分割は戦略的に考えてください。例えば、ダイアログSoundBankを分割する場合には、単一のキャラクターのすべてのセリフを含むバンクの作成を避けます代わりに、コンテキストに従ってダイアログをグループ化します。
AK::SoundEngine::ExecuteActionOnEvent API を利用して、イベント数を減らす。Play/Stop のペアを単一のPlayイベントに置き換えて、AK::SoundEngine::ExecuteActionOnEvent の "ExecuteActionOnEvent" を呼び出し、Stop ならびに Pause/Resume します (同じ Play イベントになります)。
ゲームオブジェクトを細かく管理すること。役割が終わったものは、すぐに登録を解除します。全くメリットがない上に、メモリを消費してしまうので、使用しないゲームオブジェクトのプールを生かしたままにしないでください。例えば、NPC が死んだ場合を考えてください。そのゲームオブジェクトの登録を解除します; 何か別のことに再利用しないでください。必要な場合には、新規のものを登録します。基本的な考え方として、数千個のゲームオブジェクトが生きている状態は、多すぎると言えます。
アクターミキサー (Actor-Mixer) をサウンドを構成するためだけに使用しないこと。フォルダとワークユニットはメモリを消費しませんが、アクターミキサーは消費します。デフォルトでない同様のプロパティを共有する場合には、そのプロパティはそこに一度しか存在しないのでメモリを節約することができます。もちろん、アクターミキサーが、SetVolumeや、SetPitchなどのイベントにレファレンスされるかどうかにもよります。
大きい階層は、サイズや複雑性を減らすように努力すること。よくある大きい階層として、「Impact（衝撃）」階層や、「Footstep（足音）」階層などがあります。これらは変数が多いため、サイズが大きくなり、構造のだめのメモリを多く必要とします。このような階層を小さくする方法を、以下にいくつか示します。
- 変化するのが、単純なプロパティであれば、RTPCを使う（サンプルは同じで、ボリューム、ピッチ、ランダマイザーなどが変わる場合）。
- Switch Container階層を、複数のサウンドバンクに分けることができます。サウンドバンクマネージャでは、Switch コンテナを含む際、すべてのその分岐も含みます。しかし、SoundBank Editor ビューの theGame Sync タブ、または Edit タブで、分岐の幾つかを手作業で除外することができます。例えば、Footstep 階層では、最初の Switch 変数は Surface Type (地面の種類) かもしれません。その場合、Switch を異なるサウンドバンクに分けて、コンテキストによってそれらをロードします。メインの Footstep サウンドバンクには、都市環境のコンクリートや金属の階段など、ゲーム全体で遭遇する地面を含み、他のコンテキストによるサウンドバンクは、ゲーム中の一つのシーン/セクションのみに使用される泥の表面など、特定の地面を含みます
「外部ソース」を利用して、Wwise アクターミキサー階層が提供するような多くの制御を必要としないサウンドのオーバーヘッドを減らす。これは通常ボイスオーバーに向いています。

Processingメモリ

Processingカテゴリのメモリは、サウンドの再生に使います。これには解凍のためのバッファを含み、エフェクトを適用し、オーディオソースをミックスします。一度に再生するサウンドの数に直接影響されます。また、同時に使うエフェクトの合計数や種類にも影響を受けます。削減するには、同時にいくつのサウンドを聞かせたいのかを決める必要があります。ゲームによって、サウンドが10個以上聞こえるシナリオがほとんどないものもあれば、100個のゲームもあります。最悪のケースを考える必要があります。

ガイドラインとして、一部のゲーム (Xbox One) でプロファイリングを行い、次の数値を得ました:

1MBで、約42個のボイスを再生
2 MB で約96個のボイスを再生ほぼ比例関係にありますが、どのコーデックを使用しているか、エフェクトの数、およびその他の要素に依存します。例えば、Vorbis コーデックでは、質の設定によりボイスあたりのメモリは50ほど多くなります。一度に170個のサウンドを再生するとします: これは恐らく理解不能で、役に立たないでしょう。しかし、ゲームのために理想的な本当の数字を見るけるための実験が必要です。プロファイラーの Memory タブを利用して、ゲームで複数のシナリオをプロファイルして、リソースでどれくらい使用しているかに留意します。

処理に使用するメモリ量を減らすには、同時ボイス数を減らしてください。それには次を利用します:

再生制限（Playback Limits）：Advanced Settingsの設定。例えば、跳弾50弾分のサウンドが聞こえる必要が、本当にあるのか。必要なければ、その数値を例えば15に制限します。

info 注釈: また、バスの数も制限できます。
Priority (優先度) : Advanced Settingsの設定。例えば、弾丸は、ダイアログほど重要でないとします。そこで、サウンド数が多すぎる場合は、まず弾丸の再生を落します。Playback limits（再生制限）と組み合わせて使います。
Distance-based Priority Offset（プライオリティの、距離に基づくオフセット）：Advanced Settingsの設定。一般的に、遠くにあるオブジェクトは、近くのものほど重要ではありません。例えば、10m先にある弾丸の音は、もっと近くに弾丸サウンドが15個ある場合は、聞こえる必要がありません。
Below Threshold Behavior（ボリュームしきい値以下の動作）：Advanced Settingsの設定。負荷が最も低い動作（CPU、メモリ）は、「Kill Voice（ボイスを消す）」です、非ループサウンドに有用です。次に望ましいオプションは、「Send To Virtual（バーチャルボイスリストに送る）」+「Play from beginning（最初から再生）」であり、その次は「Send To Virtual（バーチャルボイスリストに送る）」+「Resume（再開）」、その次は「Send To Virtual」+「Play from elapsed time（経過した時間から再生）」と続きます。最も負荷が高いのは「Continue to play（再生を続ける）」と、「Play from elapsed time（経過した時間から再生）」のオプションです。Wwiseのデフォルト値は「Continue To Play（再生を続ける）」なので。

Volume Threshold (ボリュームしきい値) :Project Settingsの設定。これは、小さすぎて聞こえないようなサウンドをキルする（消す）ために使います。この設定と共に使われるのは、閾値以下の動作設定（Below Threshold Behavior）や、遠くに行けば一般的に音が小さくなる減衰（Attenuation）設定です。

info

注釈: プログラム的にボリュームのしきい値をランタイムで変更できます。「ボリュームしきい値以下」の状態により多くのボイスを送るために、より処理が重くなるゲームの箇所でこれを利用できます。

使用したコーデック設定への変更 (Conversion Settings)。Vorbis は、オーディオを解凍するために余分なメモリが必要です。異なるパラメータが、必要量を増やしたり、減らしたりします。しかし、そのコストも充分に考慮する必要があり、コーデックを変えたり圧縮率を下げたりするとProcessingメモリに対する負荷が軽減される一方、ファイルをバンクにロードするのであれば、メモリ内のファイルサイズが大きくなってしまいます。場合によっては、Processingメモリの使用量を500 KB増やしてでも、Media メモリで数MBセーブできるのであれば、オーディオ予算全体の節約につながります。
質を少なく、または低くする。一部のエフェクトは処理に多くのメモリを必要とします。非常に一般的に、利用可能などの場合においてもメモリを多く消費するのが Reverb エフェクトです。現実的には、ゲームは非常に少ない数のリバーブしか同時に実行できません。ルールとしては、4個未満を推奨します。また、リバーブの質を低くする、長さを短くすることは助けになります。

メディアメモリ (サウンドバンク)

サウンドバンク（SoundBank）のメモリ消費は主に、中にあるサウンドデータに起因します。サウンドデータ（メディア）のメモリ消費は、以下のテクニックで抑制できます。

多数のサウンド構造やEventを入れた大きいサウンドバンクは、いくつかの小さいサウンドバンクに分割する。必要に応じて、ロード、アンロードします。
ディスクからストリーミングするサウンドの数を増やす（サウンドオブジェクトのプロパティ）。レイテンシに敏感なサウンドは、事前にフェッチしたメディアを使うことができ、 PinEventInStreamCache APIを使用して事前にロード、またはオンデマンドのキャッシュにストリームすることができます。
APIの、PrepareEvent()を使う。
オーディオの圧縮率を上げる（コンバージョン設定、コーデックなど）。
サンプルレートを下げる。Automatic Sample Rate Detection（サンプルレート自動検知）機能を検討してみる（Conversion Settings）。
風（Wind）関連のサウンドを、プラグインSoundSeed Wind/Wooshの同等サウンドに置き換える。風のアンビエントサウンドは、ループサウンドであることが多く、メディアスペースをかなりとります。ブレードのヒューという音、プロペラ、窓を開けた車での風が勢い良く流れる音、換気の騒音、その他はこのプラグインで作り出すことができます。また風とは関係のない応用も考えられます: どのような騒々しい音も作りだすことができます。例: 海の波、または遠くから聞こえる高速道路の音など。

「Temp Alloc」メモリの調整

Wwiseはメモリの内部プールを使用して一時アロケーションを管理しますが、アロケーションが存続するのは1つのオーディオレンダリングティックが終了するまでです。一時アロケーションはAdvanced Profiler's Memoryタブでは「Temp Alloc」と表示されます。こうした一時アロケーションが存在するのは一定時間であるため、オーバーヘッドがほとんど発生しません。またサウンドエンジンで内部的に処理され、デベロッパが提供するメモリアロケーションフックには転送されません。これに関連するアロケーションでAdvanced Profilerとメモリアロケーションフックによって監視されるのは、一時アロケーションの作成元となる大きなメモリブロックのみです。このため、ゲームでのメモリ使用量を最適化するためには、「Temp Alloc」メモリブロックの管理を手動で調整することが望ましい場合があります。

AK::MemoryMgr::Init の実行時に、 AkMemSettings::tempAllocSettings によってTemp Allocカテゴリごとにメモリブロックの動作が制御されます。特に注目すべきは、メモリブロックのサイズ、システムがアロケーションを存続する最小ブロック数、およびシステムがメモリの解放を開始する前に1回のティックで確保する未使用のブロック数の設定が含まれていることです。 AK::TempAlloc::GetStats() を使用してゲーム実行中にTemp Allocシステムが使用するメモリ量を確認し、システム設定をより適切に微調整できます。

以下は、ゲームの要件やプロファイリング中に観察された動作に応じた推奨事項です。

メモリブロックの割り当てと解放に伴うオーバーヘッドやメモリブロックの解放時に発生するメモリフラグメンテーションに関する懸念がなければ、任意の時点でゲームに必要なメモリ使用量と一致するように AK::TempAlloc::InitSettings::uMinimumBlockSize をデフォルト値より小さい値に設定することが望ましい場合もあります。
ブロックの割り当てと解放が原因で過剰なメモリフラグメンテーションが発生する場合は、 AK::TempAlloc::Stats::uPeakMemUsed を測定してTemp Allocシステムのピーク時のメモリ使用量を確認してから、使用する可能性のあるブロックがすべてサウンドエンジンの初期化時に割り当てられ、後に解放されないくらい十分な大きさの値が AK::TempAlloc::InitSettings::uMinimumBlockCount に設定されていることを確認してください。
ピーク時のメモリ使用量を評価せずにメモリブロックが解放されないようにするには、 AK::TempAlloc::InitSettings::uMaximumUnusedBlocks を大きな値に設定することで、システムは新しいブロックを割り当てるが、メモリの負荷が低い時でもブロックを解放しないようにすることができます。
Job Managerを利用したオーディオレンダリングジョブの同時実行で説明されているように、Job Managerをオーディオレンダリングに使用している場合、メモリブロック数は増加します。メモリブロックはすべてスレッドローカルであり、一般的にアクティブワーカーごとに1つのメモリブロックが割り当てられるためです。使用するワーカーが増えてもゲーム内で使用されるメモリが著しく増えないように、AK::TempAlloc::InitSettings::uMinimumBlockSize を小さな値にすることが望ましい場合があります。

AK::TempAlloc::InitSettings にはデバッグオプションがいくつか用意されています。サウンドエンジンのDebugおよびProfile設定では、メモリ使用量統計のトラッキングを改善してバッファオーバーランを簡単に検出できるように、 AK::TempAlloc::InitSettings::bDebugDetailedStats および AK::TempAlloc::InitSettings::bDebugEnableSentinels がデフォルトで有効になっています。アプリケーションでパフォーマンスの最大化や最も正確なプロファイリングデータが必要な場合は、これらのオプションを無効にします。サウンドエンジンのReleaseコンフィギュレーションでは、これらのオプションに関するサポートが完全に削除されています。

「Bookmark Allocator」メモリの調整

Wwiseには、1つの関数やコードブロックが実行される間だけ存在する短期メモリアロケーションを処理するための「Bookmark Allocator」と呼ばれるシステム（「Temp Alloc」と似たシステム）が備わっています。これにより、Wwiseは一時メモリのアロケーションをメモリがスタック上にあるかのようにして実行できます。ただし、Bookmark Allocatorは考えられるすべてのシナリオに対応するために、スレッドの十分な大きさのスタックに割り当てられたメモリに依存するのではなく、通常のメモリアロケーションを使用して必要なリソースを提供します。

AkMemSettings::bookmarkAllocSettings を使用すると、下層のメモリブロックの割り当てと解放を実行するために用意されている「Bookmark Allocator」メモリカテゴリのメモリブロックの動作を制御できます。バッファオーバーランを検出して、決定的な無効値に割り当てられたメモリを使用の前後にクリアするためのデバッグ設定も用意されています。AK::BookmarkAlloc::GetStatsを使用して「Bookmark Allocator」のしくみを知ることができます。

以下は、ゲームの要件やプロファイリング中に観察された動作に応じた推奨事項です。

AK::BookmarkAlloc::Stats::uRecentBlocksFetched を大きな値にすると、マルチスレッドシナリオで過剰なスレッド競合が発生することがあります。このため、「Bookmark Allocator」で使用されるブロックを大きくし、新しいブロックの一時的な要求が頻繁に発生しないように、 AK::BookmarkAlloc::InitSettings::uMinimumBlockSize の値を上げることが望ましい場合もあります。必要な最小ブロックサイズを決める際に AK::BookmarkAlloc::Stats::uRecentPeakMemUsed が役立ちます。
反対に、提供されているメモリのすべてを使用していないことが分かった場合は、 AK::BookmarkAlloc::Stats::uPeakMemUsed を測定して AK::BookmarkAlloc::InitSettings::uMinimumBlockSize のサイズを小さくすることもできます。
Job Managerをオーディオレンダリングに使用している場合、 Job Managerを利用したオーディオレンダリングジョブの同時実行で説明されているように、使用されるブロック数は増えます。メモリブロックはすべてスレッドローカルであり、一般的にアクティブワーカーごとに少なくとも1つのメモリブロックが割り当てられるためです。またこれにより、2つの理由からメモリブロックの割り当てと解放が頻繁に発生する可能性もあります。1つはメモリブロックの非決定的な取得が多く発生する可能性があること、もう1つはサウンドエンジンティックの実行中にメモリブロックが取得されないため、一部のメモリブロックが未使用とみなされる可能性があることです。長時間の安定したメモリ使用を確保できるように、AK::BookmarkAlloc::InitSettings::uMaximumUnusedBlocks の値を上げることが望ましい場合もあります。または、ジョブによって取得される最初のブロックで必要なすべてのメモリ量を確保できるように AK::BookmarkAlloc::InitSettings::uMinimumBlockSize の値を上げることもできます。

このページはお役に立ちましたか？

サポートは必要ですか？

ご質問や問題、ご不明点はございますか？お気軽にお問い合わせください。

サポートページをご確認ください

あなたのプロジェクトについて教えてください。ご不明な点はありませんか。

プロジェクトを登録していただくことで、ご利用開始のサポートをいたします。

Wwiseからはじめよう

Wwise SDK

メモリ使用量を抑えるヒント