バージョン
ゲームのオーディオメモリを効率的に管理するための、コツやベストプラクティスについて、以下のセクションを参照してください。
本書の別のセクションでも述べた通り、サウンドエンジンのメモリプールの1つ、または複数に対して、メモリ閾値(Memory threshold)を設定することができます。オーディオプログラマーが、サウンドエンジンの初期化パラメータにある以下の値を変更することで、メモリプールの閾値(Threshold)を設定できます。
AkInitSettings::fDefaultPoolRatioThreshold
AkPlatformInitSettings::fLEngineDefaultPoolRatioThreshold
デフォルトで、メモリ閾値にデフォルト値「1」(つまり100%)を設定して、解除してあります。有効にするには、「0」から「1」までの間の数値を設定します。
メモリ閾値が解除されている時は、メモリアロケーション機能(Memory allocator)が正常に作動します。閾値を有効にすると、メモリの使用率を、指定した閾値よりも低く維持するために、エンジンが定期的にチェックします。閾値を超えると、最低プライオリティのサウンドを、システムが順にドロップし始めます。
メモリ閾値が設定されていない状況では、エンジンは各サウンドのプライオリティを遵守しますが、メモリ量が少なくなると、高プライオリティのサウンドを再生するメモリが不足してしまえば、それをドロップします。メモリ閾値を設定してある場合は、プライオリティの低いサウンドからドロップして、プライオリティが高いサウンドのためにスペースを空けます。
まとまった量のデータをメモリに追加したり削除したりすると、多少のフラグメンテーションが必ず発生します。Wwise自体がメモリフラグメンテーションの対処を行うことはありませんが、発生するフラグメンテーションを減らすためにメモリプールの設計で考慮してあります。
デフォルトメモリプールは、主にサウンド構造のメタデータ用に使われ、主に小さいオブジェクトが入っているので、フラグメンテーションの問題はそれほどありません。ロワーエンジンメモリプールは、オーディオのパイプラインと処理のために確保してあり、大きいブロックで構成されますが、オーディオが消えると、これらのブロックは開放されます。この2種類のメモリプールに関しては、それぞれ約10%のオーバーヘッドを割り当てるだけで、フラグメンテーションをほぼ完全に回避できます。
一方、様々なバンクに保存されるオーディオデータは、LoadBank()コールごとに、ユーザーが設定する別のプールにコピーされるので、オーディオデータのメモリ管理に関しては、オーディオプログラマーが細かくコントロールできます。メモリフラグメンテーションの発生を最小限に抑えるために、オーディオプログラマーは、CreatePoolのために AkFixedSizeBlocksModeフラグを送ることで、サイズが固定されたブロック(Fixed size blocks)のプールを使い、ブロックサイズを、各プールの最大のSoundBankのサイズにします。これで、全てのSoundBankを、最大バンクのサイズと同じであるように配分されます。もちろん、プールが複数あり、プールごとに、特定のSoundBankサイズに合わせて、スロット(ブロック)を一定数提供するという方法も可能です。AkFixedSizeBlocksModeプールのメモリブロックは、GetBlock()で取得され、常に同じサイズとなります。このテクニックで、フラグメンテーションを完全に回避できます。