목차

Wwise SDK 2019.2.0
Optimizing Memory Allocation
참고: 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.

Fixed-size allocations

Some of the fixed-size allocations can be controlled via initialization parameters. Here is a list of init-time memory allocation controls:

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.

Dynamic allocations

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.

참고: You can also explore sound engine memory usage in the Memory tab by capturing profile information from Wwise itself without connecting to a game.

Running out of Memory

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.

Detecting Memory Problems

Wwise Profiler를 사용하면 게임에서 메모리 할당이 실패할 때마다 Capture Log에 경고 알림이 뜹니다. You can check this list of notifications to find out which memory categories were involved in reaching the memory limit during gameplay.

Causes of High Memory Usage

다음 아이템은 메모리 사용량을 높일 수 있습니다.

  • Loading banks increases Object and Media memory usage. 각 뱅크가 사용하는 메모리의 양이 다르다는 점을 주의하세요. 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. 그렇지 않으면 메모리 사용량이 계속 증가합니다.

주의:

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:

참고