Version

menu_open

Memory Management Tips and Best Practices

The following sections provide you with a series of tips and best practices that can help you effectively manage the audio memory in your game.

Using the Memory Threshold

As mentioned briefly in an earlier section of this document, you also have the option to define a memory threshold for one or more of the sound engine's memory pools. The audio programmer can define a threshold for a memory pool by modifying the following values in the initialization parameters of the sound engine:

  • AkInitSettings::fDefaultPoolRatioThreshold

  • AkPlatformInitSettings::fLEngineDefaultPoolRatioThreshold

By default, the memory threshold is disabled using a default value of 1 (or 100%). You can enable it by setting a value ranging anywhere between 0 and 1.

When the memory threshold is disabled, the memory allocator will work normally. When enabled, the engine periodically checks that the percentage of memory being used is below the specified threshold. If it goes over the threshold, the system will start dropping sounds with the lowest priority.

In situations where the memory threshold is not used, the engine will honor priorities of sounds, but in low-memory conditions, the engine may not have enough memory to play a sound with a high priority, which means that it would get dropped. When the memory threshold is used, sounds with lower priorities will be dropped to free up space for the higher priority sound.

Dealing with Memory Fragmentation in the Sound Engine

Whenever you are dealing with chunks of data being added and removed from memory, you will have some amount of fragmentation. Wwise does not, by itself, deal with memory fragmentation, but the memory pools have been designed to reduce the amount of fragmentation that occurs.

The default memory pool, which is used mainly for sound structure metadata, consists mainly of small objects, so fragmentation is not really an issue. The lower engine memory pool, which is reserved for the audio pipeline and processing, does consist of larger blocks, but these blocks all get freed when the audio dies down. For both of these memory pools, by simply allocating an overhead of approximately 10% to these pools, you can avoid fragmentation almost entirely.

As for the audio data that is stored in banks, it is copied in a separate user-defined pool for each LoadBank() call, giving the audio programmer great control over the memory management of audio data. To minimize any memory fragmentation that may occur, the audio programmer can try using fixed-block-size pools by passing the AkFixedSizeBlocksMode flag to CreatePool, with the block size being your largest bank for each pool. This will allocate every bank as if it were the size of the largest bank. Of course, you can have more than one pool, where each pool gives you a given number of slots/blocks for a certain size of bank. Memory blocks of AkFixedSizeBlocksMode pools are obtained through GetBlock() and always have the same size. By using this technique, fragmentation can be completely avoided.


Cette page a-t-elle été utile ?

Besoin d'aide ?

Des questions ? Des problèmes ? Besoin de plus d'informations ? Contactez-nous, nous pouvons vous aider !

Visitez notre page d'Aide

Décrivez-nous de votre projet. Nous sommes là pour vous aider.

Enregistrez votre projet et nous vous aiderons à démarrer sans aucune obligation !

Partir du bon pied avec Wwise