Table of Contents

Understanding Secondary Outputs

The term "secondary output" refers to any of the audio outputs that are not the main TV or main speakers. For these outputs, a separate audio mix must be done depending on the context. You can have as many master secondary busses as you need for each of the expected outputs of the game. The most common secondary output is the speaker or headphones on game controllers. There can be other independent outputs as well (chat, background music, headphones, and so on). For the rest of this section, the discussion will be around the game controller speakers, but the information can apply to all other types of outputs.

To output something on a secondary output, sounds need to be routed to the master secondary bus hierarchy using one of the two following approaches:

  • Setting the Output Bus property of a sound directly to any bus in the secondary bus hierarchy. This works the same way as any other sound routing. This is the preferred method for sounds that are normally tied to only one secondary output instance. Some examples include player-initiated gunshots, tennis racket whacks, PDA sounds, and gameplay feedback.

  • Routing a sound through any bus in the 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 from multiple outputs and/or the TV at the same time. Some examples include a spy camera and 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 secondary bus.

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. This is illustrated in the following examples.