Table of Contents
Wwise SDK 2019.2.9
|Note: The memory manager has been completely revised for Wwise version 2019.2. The following instructions only apply from version 2019.2 onwards.|
The Wwise sound engine memory allocations can be divided into two broad groups: a number of fixed-size allocations made upon sound engine initialization, and dynamic allocations.
Some of the fixed-size allocations can be controlled via initialization parameters. Here is a list of init-time memory allocation controls:
- AkInitSettings::uMonitorQueuePoolSize (Debug/Profile only)
Of these, uIOMemorySize is the most significant. This streaming buffer size should be set based on the maximum number of concurrently played streamed sounds, the bitrate of the sounds, and the safety timeline of the streaming sounds. The default value of 8 MB may be seen as a waste of memory for some games, but it is best to start out large and trim down as your memory usage becomes clearer. For more information on streaming buffer memory, refer to Audiokinetic Stream Manager Initialization Settings.
See the documentation for memory allocation categories in AkMemID to get a better understanding of the various types of allocations made by the sound engine. Statistics for each of these categories are reported in the Memory tab of the Wwise Advanced Profiler View.
Debug-only allocations are made in the Monitor Queue and Profiler categories, which are not used in the Release version. Subtracting the size of these categories should give you a good idea of the release-version memory usage.
|Note: You can also explore sound engine memory usage in the Memory tab by capturing profile information from Wwise itself without connecting to a game.|
Total memory allocation by the sound engine can be controlled via the AkMemSettings::uMemAllocationSizeLimit initialization parameter. With a limit set, the sound engine reacts differently to out-of-memory conditions depending on when the condition occurs. For example, here is what happens when memory is missing in the following scenarios:
- Sound engine initialization: The initialization fails.
- Loading a bank: The bank load fails.
- Starting a transition for a parameter, such as volume: The transition is skipped and the parameter jumps directly to the target value without transition.
- Playing a sound: Either the play fails or another playback with lower priority is stopped to free memory for the new one.
When you use the Wwise Profiler, a warning notification is sent to the capture log for every allocation failure that occurs in the game. You can check this list of notifications to find out which memory categories were involved in reaching the memory limit during gameplay.
The following items can cause high memory usage:
- Loading banks increases Object and Media memory usage. Note that each bank uses a different amount of memory. Memory used by a bank in the Object category does not depend on the physical size of the bank but on the number of structures and events that it contains.
- Some effects, including reverb and delay, consume a larger amount of Processing memory when playing.
- Playing multiple sounds at once drastically increases the amount of Processing memory used.
- Sending multiple actions in a short amount of time increases the amount of Object memory used.
- Registering game objects, setting "per object" parameters, and setting object positions all use a small amount of memory. However, be aware that unused game objects must be unregistered to free up this memory. Otherwise, the amount of memory being used constantly increases.
|Warning: When performing tests to check peak memory usage, you must ensure that the current speaker setup configuration used by the game is set to its maximum configuration (for example, 7.1 on PC when using the system audio output device). This is necessary because the sound engine performs some optimizations when the speaker setup is stereo, and therefore will use less memory than in multi-channel configurations.|
More details are available in the following sections:
- See also