Wwise Help

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:

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.

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.