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:
Limiting the number of instances that can be played per game object or globally on one or more Actor-Mixer Hierarchy or Interactive Music Hierarchy objects and their children;
Limiting the overall number of instances that can pass through a bus; or
Limiting the overall number of instances in the entire game.
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.
To define a Playback Limit:
Load an object into the Property Editor.
Switch to the Advanced Settings tab.
In the Playback Limit group box, select the Limit sound instances to option.
The Playback Limit options become available.
In the corresponding text box, type the maximum number of instances that can be played simultaneously per game object.
To define the scope for the Playback Limit, select one of the following options:
Global to apply the limit globally.
Per game object to apply the limit per game object.
![[Note]](/images/2022.1.17_8543/?source=Help&id=note.png)
Note This option is not available on busses because the limit is always global.
To determine what happens when the Playback Limit is reached, select one of the following options:
Kill voice to stop the playing instance with the lowest priority.
Use virtual settings to adopt the defined virtual voice behavior for the sounds. The sounds' virtual behaviors are Continue to play, Kill voice, Send to virtual voice, and Kill if finite else virtual.
To determine what happens when the Playback Limit is reached and there is more than one object with the lowest priority, select one of the following options from the When priority is equal list:
Discard oldest instance to stop the oldest playing instance with the lowest priority.
Discard newest instance to stop the newest playing instance with the lowest priority.
The Project/Game limit can be modified in the Wwise Project Settings, per platform. It may also be changed by the game using the Wwise SDK API once the sound engine is properly initialized.
When working with the voice limitation system, it is good to know the following:
Virtual voices do not count as valid voices.
Sounds with the virtual voice setting set to Continue to play may cause the limit to be exceeded.
Sounds that are sent to virtual voice can normally be set to Play from beginning, Play from elapsed time, or Resume upon return to physical voice (no longer virtual). However, in the case of the Kill if finite else virtual option, sounds that are sent to virtual voice are always set to Play from elapsed time upon return to physical voice.
For example, let us suppose you have:
A limit on a bus set to 4 simultaneous sounds.
The When limit is reached behavior on this bus is set to Use virtual voice settings.
The Volume Threshold is set to -60 dB.
You have 8 voices playing at this frame in this bus.
|
Sound name |
Priority |
Volume |
Virtual Behavior |
|---|---|---|---|
|
Sound_1 |
100 |
0 dB |
Go Virtual |
|
Sound_2 |
90 |
-90 dB |
Go Virtual |
|
Sound_3 |
80 |
-90 dB |
Continue to play |
|
Sound_4 |
70 |
0 dB |
Go Virtual |
|
Sound_5 |
60 |
0 dB |
Kill voice |
|
Sound_6 |
50 |
0 dB |
Kill voice |
|
Sound_7 |
40 |
0 dB |
Go Virtual |
|
Sound_8 |
30 |
0 dB |
Continue to play |
The result would be:
|
Sound name |
Result |
Reason |
|---|---|---|
|
Sound_1 |
Play (1/4) |
Highest priority and over volume threshold. |
|
Sound_2 |
Will go virtual |
Volume under threshold. |
|
Sound_3 |
Play (2/4) |
Continues to play even when under volume threshold. |
|
Sound_4 |
Play (3/4) |
- |
|
Sound_5 |
Play (4/4) | - |
|
Sound_6 |
Will be killed |
Over limit, already 4 sounds with higher priority are playing |
|
Sound_7 |
Will go virtual |
Over limit, already 4 sounds with higher priority are playing |
|
Sound_8 |
Play (5/4)* |
*Will play even if the limit is exceeded, this is a special situation where this sound is not allowed to go virtual nor be killed, and is not allowed to take over the 4 sounds already playing with a higher priority. |
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.
Related Topics
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