Wwise Help

To deal with limited game resources or game-design constraints, you must optimize the sounds, music, and motion objects that are playing at any one point in the game. You can manage the simultaneous playback of the various objects in your project using three different methods:

When either limit is reached, Wwise uses the priority setting of the object to determine which one to discard based on the selected behavior to adopt when the limit is reached. If objects have equal priority, you have the option to discard the newest or oldest instance that is playing.

When you set a playback limit at the Actor-Mixer or Interactive Music level, you control the number of instances within the same structure that can be played either globally or per game object. If a child object overrides the playback limit set at the parent level, the total number of instances that can play is equal to the sum of all limits defined within the structure. This means that if, for example, you have a parent with a limit of 20 and a child with a limit of 10, the total possible number of instances is 30.

When you set the playback limit at the Master-Mixer level, it specifies the number of sound, music, and/or motion instances that can pass through the bus at any one time. Since the priority of each object has already been specified at the Actor-Mixer or Interactive Music level, there is no playback priority setting for busses.

When you set the playback limit at the project/game level, it specifies the number of sound, music, and/or motion instances that can be active at any one time. Each sound will adopt its own Virtual Voice behavior set in its Advanced Settings.

When working with voice limitation system, it is good to know the following:

For example, let us suppose you have:

The result would be:

FAQ

Q: The limit does not seem to be working? Why?

A: Check if the sound's virtual behavior is not set to “Continue to play”, it is the default value for compatibility reasons. Any sound with this setting will not be kicked nor virtualized when over the limit (unless the over limit behavior was set to kill voice explicitly). Once you start using the “Use Virtual Voice settings” when over the limit, you must set this setting for any sound that would be considered “kickable” or “virtualizable” to start saving some CPU.

Q: The limit seems to be working most of the time but the profiler sometimes shows values that are over the specified limit even if none of these sounds are set to “Continue to play”.

A: When sounds are becoming virtual, they stay active for a few ms (one audio frame) to fade out and avoid clicking. For example, if the limit is set to 1 and one sound is already playing, then another sound pops in with a higher priority, the number of active voice will temporarily be to 2 while the first sound is fading out to go virtual.

Q: Why is sending to virtual voices not the default setting when over limit? Why are all sounds set to continue to play by default?

A: Some source codec may not be perfectly accurate in virtual mode and/or could require a seek table to be added in the source to be able to work in virtual voice: play from elapsed time. For this reason and to ensure that everything runs fine by default, this is not the default setting. For example, Vorbis will require a seek table to be able to properly adopt a virtual behavior with the From Elapsed time setting.