Structuring a Bus Hierarchy

Structuring a Bus Hierarchy - Example

Wwise provides great flexibility in structuring a bus hierarchy. This means that there is no universally correct way to organize your project's sound structure. Still, the following simple example provides overall general practices for the development of a bus structure regardless of a project's mix of assets and requirements.

In the following screenshot, drawn from the Schematic View, we see a project organized with four Audio Busses under a master Audio Bus and three secondary master busses.

For the Master Audio Bus, we have the following busses:

Environmental Bus - This bus groups the various sounds the player is likely to hear based on different environmental factors (reverbs for example), such as footsteps (the player's or other characters') on gravel, wood, or cement floors.
Music - This bus groups all the music, whether while playing in certain settings in the game or moving through UI menus outside of the game.
Voices - This bus groups most of the character dialogue.
Voices_Radio - With a lot of dialogue in this game, and many voices needing special settings to represent their sound over a radio, we've also added this bus separate from the Voices bus. Among other ways we could have organized it, we might have set it as a child bus of the Voices bus. But, although conceptually similar, the desired sound output and the mixing it would imply made it easier for us to define it as a separate bus directly under the Master Audio Bus.

To make it easier to apply adjustments to sounds based on being located in a large airplane hangar, we also added an Auxiliary Bus: Hangar_Env. This way, when the game scene moves to the hangar, we can send sounds - manually or through a game call - to this bus where we apply a reverb reminiscent of the open echo one might hear in such an environment.

Then we have additional master busses, each feeding a secondary output:

Motion Bus - This bus receives all motion signals (also known as rumble) and will output them to the appropriate controller. In this example, there is no child bus, although it is possible to have more complex mixing for motion too.
Non Recordable Bus - It is possible for a system to have a separate output that will not be recorded by a DVR (Digital Video Recorder). This is ideal for copyrighted music that should not be distributed through player's recording. The sounds (or music) that are routed to this bus will not be recorded.
Game Pad Bus - A controller speaker which can output sounds that the player will hear more directly or, at least, distinctively. This is ideal in such cases as the clunk of the character's head hitting the wall.

	Tip
	It is not recommended to send the same sound at the same time to both a secondary and an Audio Bus! Every system has its own level of latency. Even if it's only a couple of milliseconds, the delay in two outputs of the same sound will create a noticeable dissonance.

	Note
	You can generate motion data from a sound object, including music files. For more information on generating motion from an existing sound object, refer to Generating Motion from Existing Sounds.

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.

Get started with Wwise

Wwise Help