Memory Manager
All modules of the Wwise sound engine access memory through the AK::MemoryMgr interface. The client of the sound engine is responsible for initializing and terminating this interface.
A default implementation is provided with the SDK as a static library (AkMemoryMgr.lib). To use this library, the client needs to define a number of functions: AK::AllocHook(), AK::FreeHook() and platform-specific variants. AK::AllocHook() and AK::FreeHook() can simply be redirected to the standard malloc and free functions, while the other allocators must go through specific OS calls as documented in AkMemoryMgr.h. The AK::MemoryMgr::Init() factory function is exposed in AkModule.h.
Refer to Build Configuration for more information regarding the usage of AkMemoryMgr.lib and other libraries.
Initialization
When initializing the memory manager, it is important to specify a maximum number of pools that are required to accommodate all modules during the lifetime of the memory manager. Depending on the build configuration and the presence of various modules, approximately 14 pools are created at initialization time, with an extra pool for every loaded bank (if no existing pool is specified when calling AK::SoundEngine::LoadBank()).
Refer to Samples for sample code and more information regarding the initialization of the Memory Manager in your game.
Refer to Loading Banks for more information regarding SoundBank memory usage.
Pools
Memory pools can be created and destroyed during the entire lifetime of the memory manager. Pools are segmented into blocks of equal size representing the smallest allocation unit. A pool, once created, cannot be resized with the default implementation of the memory manager. Refer to Overriding the memory manager for information regarding the implementation of a custom memory manager.
|
Note: Banks containing XMA files on the Xbox360 need to be loaded in pools created with the AkPhysicalAlloc type. |
|
|
Note: Each pool that is created has an extra 7.2 KBytes added to it for internal pool management. When creating a pool with the pool size equal to the block size, no extra memory overhead will be attached to it. It is important to use pools even for a single block of memory so that all memory statistics are visible in the Wwise profiler. Refer to Optimizing Memory Pools for information about choosing the best sizes for pools. |
Overriding the memory manager
It is possible for a client to implement the AK::MemoryMgr interface. Here are a few things to watch for when doing so.
AK::MemoryMgr::CreatePool() must respect the allocation type parameter.
A client could choose to make the maximum number of pools dynamic, and the individual pools resizeable; this offers more flexibility to the sound engine at the expense of predictability.
Refer to the AK::MemoryMgr namespace for a detailed description of the methods you need to implement when overriding the default Memory Manager.
Was this page helpful?
Need Support?
Questions? Problems? Need more info? Contact us, and we can help!
Visit our Support pageTell us about your project. We're here to help.
Register your project and we'll help you get started with no strings attached!
Get started with Wwise