Wwise Help

To deal with limited game resources or game-design constraints, you must optimize the objects that are playing at any one point in the game. You can manage the simultaneous playback of the various objects in your project by:

When a 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 ignores the playback limit set at the parent level, it is no longer part of the limit hierarchy. Instead, the total number of instances that can play is their sum. This means that if, for example, you have a parent with a limit of 20 and a child object set to Ignore parent with a limit of 10, the total possible number of instances is 30. If, however, the child were not set to Ignore parent, then the total possible number of instances would be 20, the same as the parent. As seen in the illustration below, limits can be placed on child objects whether or not the parent is ignored. This allows for minute playback control over the maximum number of instances for a particular object and its descendants.

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 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 the 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 neither 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.

Also keep in mind that the limit applies only to sound objects that are within the selected object's hierarchy. If a child object has the Ignore Parent option enabled, it is no longer part of that limiter hierarchy and is not controlled by the parent's limit.

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 voices will temporarily be 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 codecs 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 as a virtual voice using the Play from elapsed time option for its return to physical voice. 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 Play from elapsed time setting.