Version
menu_open

Understanding how SoundBanks are loaded in a game

Before learning how to create, populate, and generate SoundBanks in Wwise, it is important to understand the different ways that SoundBank information can be loaded and managed by your game. The optimal method depends on a number of different factors, including the type of game you are developing, the platforms on which it will run, and the constraints set by the project team itself.

In an attempt to be as flexible as possible and to meet the requirements of almost any type of game, Wwise offers several different methods for loading audio and motion in a game, including the following:

Loading full SoundBanks

The traditional method of loading SoundBanks uses SoundBanks that contain a mix of Event data, object structure data, and media. The entire contents of these SoundBanks are loaded and unloaded at particular points in the game to ensure that Event data and related media are ready to be played when triggered.

The following illustration demonstrates how SoundBanks created using the traditional method are loaded and unloaded from platform memory as the player moves from Level 1 to the Level 2 in the game.

Since all the data and media for a particular SoundBank are loaded into memory at the same time, this method not only ensures that all data and media are ready to play when required, but it performs very little disk seeking during gameplay, which frees up the disk for other disk intensive tasks.

The main drawback with this method is that a substantial amount of memory is taken for the entire time that the SoundBanks are loaded, which gives you less flexibility when dealing with large, sophisticated games. This method also explicitly loads all the content within a SoundBank without verifying to see if media files are already loaded into memory. This might cause the same media file to be loaded into memory more than once. Despite these drawbacks, the traditional method can still be useful in many situations. For example, in a typical pinball game, where all data and media must be available at all times.

Preparing SoundBanks (all content)

To overcome some of the drawbacks of the LoadBank() mechanism, you can prepare your SoundBanks instead of loading them using AkBankContent_All(). When using this method, your SoundBanks might still include all content types (Events, structure data, and media files); but, instead of loading the media files outright, this method loads all media into memory by using the PrepareEvent() mechanism. By using this mechanism to load media, Wwise first checks to see if a media file already exists in memory before loading it. This keeps memory usage at a minimum by avoiding any duplication of media files in memory.

Along with memory savings, this method also guarantees that disk access is sequential. This avoids the random disk seeking that is likely to occur when Events are prepared one at a time using PrepareEvent().

The following illustration demonstrates how the "Prepare Bank (All Content)" mechanism loads metadata and content into your platform's memory.

When loading a SoundBank with Vorbis-encoded or WEM Opus-encoded media, it is possible to decode these media files into uncompressed PCM files with the Preparation_LoadAndDecode preparation type. This results in a larger SoundBank, but your media will be immediately available without needing to decode when an Event calls them.

Preparing Action Events

The PrepareEvent() method dynamically loads the media only when it is absolutely required. With this method, the Action Event metadata must be in a SoundBank and the associated media files must be accessible in the file system. The corresponding structure metadata can be included in the same SoundBank as the Events or in a separate SoundBank. When using this method, the SoundBank that contains the Action Event metadata is loaded and kept in memory using LoadBank(). Prior to Action Events being called by the game, they are "prepared" by the sound engine. Preparing an Event loads all referenced media files from the file system, and also loads all referenced structure metadata from a SoundBank, if it is not already loaded. When the Action Event is no longer required, it can be "unprepared" and the corresponding media files are purged from memory. To keep memory usage at a minimum and to avoid any duplication of media files in memory, Wwise performs a check before loading any media file to ensure that it is not already in memory.

[Note]Note

Only Action Events can be prepared in advance. The "PrepareEvent()" method does not work with Dialogue Events.

The following illustration shows how Events can be prepared in advance so that only required media files are loaded into memory.

When the metadata (also referred to as structures) is not stored in the same SoundBank as the Events, Wwise needs a way to find the corresponding data that resides in another SoundBank. To do this, Wwise includes references to the corresponding content stored in other SoundBanks. Wwise can use either names or IDs to refer to other SoundBanks. To use the SoundBank name in the sound engine, you must select the Use SoundBank Names option on the SoundBanks tab of the Project Settings dialog. To use IDs, deselect that option. For more information, refer to SoundBanks Tab.

Media that is referenced by a SoundBank must be stored as loose files on disk or, otherwise, be resolvable by the low level IO (such as in a File Package).

This method is generally very efficient in terms of memory usage, but it does require additional disk seeking, which might not be appropriate in situations where many files are already being streamed from the disk. Also, in cases where the game uses States and Switches, media files could be loaded into memory unnecessarily. For example, if you have different crowd sounds for the different moods or energy levels of the crowd within your game, you wouldn't want to load all of them into memory if only the angry Switch sounds are valid within a particular zone of the game. To overcome this problem, you can also "prepare" specific States and/or Switches that load only those media files that are associated with the prepared States or Switches.

The following illustration shows how Switches can be prepared in advance to further limit the amount of media that is loaded into memory at any particular point in the game.

Although preparing Game Syncs in advance can optimize memory usage, be aware that it also reduces the speed at which media is loaded into memory. Longer read times result from the sound engine needing to seek through the disk to find the sounds that correspond to the prepared game syncs.

By dynamically loading only those audio files that are required, this second method gives you greater flexibility to handle situations where you have either very large zones or levels with many sounds or very limited amounts of memory available to store both Event data, structure data, and media.

As you can see, each method has its own strengths and weaknesses. The optimal method depends on the specific scenarios, requirements, and limitations of your game. After deciding on a strategy, whether it be a single method or a combination of several methods, you can begin to populate and fine-tune your SoundBanks accordingly.

[Note]Note

The LoadBank, AkBankContent_All, PrepareEvent, PrepareGameSyncs, and AkBankContent_StructureOnly functions are accessible through the Wwise API. For more information on loading SoundBanks and preparing Events and/or game syncs, refer to the Integrating Banks section of the Wwise SDK.

For a detailed overview of the different methods you can use to manage your SoundBanks, refer to Strategies for managing SoundBanks.


Was this page helpful?

Need Support?

Questions? Problems? Need more info? Contact us, and we can help!

Visit our Support page

Tell 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