Version
menu_open

Building the structure of output busses

A bus is a grouping of your project objects for mixing and final output, which we detail in Managing Output. But, well before finishing your project, it is important to understand the role of different busses and how they work within your overall project structure.

Just as you need to define the structure for your project assets to manage them strategically, you also need to organize the output for your project. By grouping output busses together in a hierarchical structure called the Master-Mixer Hierarchy, you can define the relative properties, the States, RTPCs, as well as the Effects for the routing of your project.

You should spend some time considering how best to organize your project routing to streamline the mixing process. For example, you would simplify the mixing of your game audio by routing such sounds as ambient music or gunfire through corresponding busses.

To begin, you must understand the default structure in your Master-Mixer Hierarchy. It consists of master busses, each with their own role and hierarchy: the Master Audio Bus hierarchy and Secondary bus hierarchies.

The Master Audio Bus hierarchy

The Master Audio Bus hierarchy is a structure of output busses through which the sounds and music in your project are routed. It consists of three different levels of functionality:

  • Master Audio Bus - The top level element in the hierarchy that determines the final output of your audio. You can rename or delete any Master Audio Busses you create. You can also apply Effects to a Master Audio Bus and move it to a different work unit or virtual folder.

  • Audio Busses - One or more optional busses that can be grouped under a Master Audio Bus to help in the organization and delivery of your sound mix. These busses can be renamed, moved, and deleted; and you can also apply Effects to them.

  • Auxiliary Busses - One or more optional busses that can be grouped under any Auxiliary or Audio Bus. Like Audio Busses, they can be renamed, moved, copied and deleted; and you can also apply effects to Auxiliary (commonly referred to as "aux") Busses. Sound objects anywhere in the project can be sent to Auxiliary Busses to adjust volume, bus configuration, positioning, and RTPC, as well as to apply Effects or States. Ducking, HDR mix, and voice adjustments are not possible in an Auxiliary Bus.

[Note]Note

Auxiliary busses cannot have Audio Busses as children. They can only have other Auxiliary Busses as children.

The following Wwise interface icons allow you to identify the two bus types: Audio Busses and Auxiliary Busses.

Icon

Represents

Audio Bus

Auxiliary Bus

The following table shows all possible processing status icons for the Audio and Auxiliary bus types. Refer to Understanding the bus icons and processing status for more information on processing status.

Icon

Represents

(Audio)

(Auxiliary)

Mixing

(Audio)

(Auxiliary)

Processing Audio Objects

(Audio)

Not Mixing

(Audio)

(Auxiliary)

Processing

By default, the sounds from the Actor-Mixer Hierarchy are routed through the Master Audio Bus. However, as you build your output structure, you can systematically route objects through the busses that you create.

[Note]Note

It is possible to create Work-Units and Virtual Folders under the Master Mixer Hierarchy. This can be useful to organize the bus structure in a team environment.

You can change the default audio routing for your project in the Default Object Values dialog. For more information about these default settings, refer to Defining the default object values for your project.

Secondary bus hierarchies

Secondary bus hierarchies are structures of Audio Busses used to mix the content that will go in any other outputs than the main (TV or speaker) output. You can create as many secondary Audio Busses as needed for the various types of outputs there will be in your project. Examples of secondary outputs are game controller speakers, chat headphones, or the DVR-bypass output. Like your primary output structure, the secondary structures can have any number of child busses and Auxiliary Busses.

Sounds routed to the master secondary bus hierarchy will be sent to the secondary output using one of the two following approaches:

  • Setting the Output Bus property of a sound directly to any bus in a secondary bus hierarchy. This is the preferred method for sounds that are normally tied to only one secondary output instance. For example, player-initiated gunshots, tennis racket whacks, PDA sounds, gameplay feedback, and so on.

  • Routing a sound through any bus in a master Audio Bus hierarchy and adding a user or game send to an Auxiliary Bus inside the secondary bus hierarchy. This is the preferred method if the same sound is going to be heard in multiple outputs and the TV at the same time, such as with a spy camera or announcements.

The bus hierarchy only defines the mixing structure. To associate that mix to a specific output, choose the appropriate Audio Device ShareSet on the corresponding master bus. See the list of Built-in Audio Devices provided with Wwise.

In the case of player-related outputs (such as game controllers and headphones) which could have multiple instances in the game, it is important to know that the associated mixing hierarchy will be duplicated for each player. The project only defines the mixing "recipe" for a specific type of output. Actual routing into which copy of the structure will depend on the Listener and Game Object associations set up by the programmer.

By default, the authoring application will route all sounds to the main sound card so you can hear your sound design. However, you can select different hardware devices for testing by going into the Authoring Audio Preferences dialog from the Audio menu.

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]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]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.

Cette page a-t-elle été utile ?

Besoin d'aide ?

Des questions ? Des problèmes ? Besoin de plus d'informations ? Contactez-nous, nous pouvons vous aider !

Visitez notre page d'Aide

Décrivez-nous de votre projet. Nous sommes là pour vous aider.

Enregistrez votre projet et nous vous aiderons à démarrer sans aucune obligation !

Partir du bon pied avec Wwise