버전

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.


이 페이지가 도움이 되었나요?

지원이 필요하신가요?

질문이 있으신가요? 문제를 겪고 계신가요? 더 많은 정보가 필요하신가요? 저희에게 문의해주시면 도와드리겠습니다!

지원 페이지를 방문해 주세요

작업하는 프로젝트에 대해 알려주세요. 언제든지 도와드릴 준비가 되어 있습니다.

프로젝트를 등록하세요. 아무런 조건이나 의무 사항 없이 빠른 시작을 도와드리겠습니다.

Wwise를 시작해 보세요