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.

Secondary output examples

All the examples will be using the bus structure shown below for the Secondary Bus hierarchy. The Main Audio Bus hierarchy is omitted. This structure will be duplicated for each of the outputs so the final mixes are independent. Note that only the required busses will be instantiated.

Figure 1. Master Secondary Bus structure

Figure 2. Simple example of a sound going to the main output

This is a simple example of one sound going to the main output. In a regular game, many of those sounds will be routed to many sub busses. But for brevity, let's assume there is only one sound playing on the TV output.

Figure 3. Simple example of a sound going to the second player's controller output

Let's play another sound, this time on the second player's game controller. This could be a menu sound for example, if that player was in the menu, but not the others. In this case, the sound is mixed normally into it's output bus and independently of the TV mix. The fact that this sound only plays on the player 2 controller is set up through the game with Listener and Game Object associations. In this case, the programmer would play the sound on a Game Object that is listened only by the Controller 2's Listener.

Figure 4. Sound going to player 1, player 2 and TV.

This example illustrates two points: a sound can be routed to multiple secondary outputs and also to the TV mix. In this example, this could be a prerecorded radio call for help from player 1, which would be heard by player 2 because they are on the same team and also on the TV because the TV point of view is close to the player 2 emitting the sound. Note that this sound's Output Bus is set to Bus 1. This bus is duplicated for player 1 and 2, as is the master secondary Bus. Clearly, the player 2's mix has to include Sound 2 (which they are the only one to hear) as well as Sound 1. Both copies of the Master Secondary Bus will have the same effects applied (if any), but won't do so on the same audio signal.

You can also notice the Send going from Sound 3 to the TV mix. All types of Sends can be used to send to another output. In this case, the call may be heard by the "camera" too (depending on distance and attenuation), so it needs to be mixed into the main TV mix and will "enter" that mix from the defined Auxiliary Bus.

Background music mixing with DVR example

The recording of copyrighted music is usually not permitted through the DVR feature of the PS4, PS5, Xbox One, and Xbox Series X. These platforms provide a special virtual device to manage the music alone and avoid recording it. In Wwise, this also means separately mixing the music, in a different hierarchy. We implemented this in the Integration Demo project. You can take look at the setup for the NonRecordable_Bus, the RecordableMusic and NonRecordableMusic sounds. From the code perspective, take a look at DemoBGM.cpp.

The NonRecordableMusic is routed to the Non Recordable Bus which outputs its signal to the DVR_Bypass output, as shown below:

Figure 5. Sound routed to NonRecordable_Bus

Figure 6. Bus Audio Device set to DVR_Bypass

On the code side, there is very little to do to have this working. The game must call AK::SoundEngine::AddOutput() with the name of the Audio Device ShareSet to initialize the output.

With the Wwise Advanced Profiler, we can see that each sound goes in separate busses and separate outputs. This is what normally happens on the supported platforms. (Note that the intermediate bus Music is omitted.)

Figure 7. Two master busses mixing in separate outputs

The DVR feature doesn’t exist on any other supported platforms, so we need to do something different. In this case you obviously don’t want to lose that music in-game, so you have to route it correctly. To resolve this you can simply unlink the Audio Device property. In the master bus Property Editor, the Audio Device property can also be unlinked. In the example below, we made the Non Recordable Bus output to the ordinary System output. It still goes to DVR_Bypass for the supported platforms though, hence the half-orange Link icon. This is what we did in the Integration Demo project. In this case, the code doesn’t need to call AK::SoundEngine::AddOutput to initialize the output since the System output is always initialized at startup.

Figure 8. Audio Device set to System output

When playing both sounds, we see that the signal from both sources goes through separate busses, but they end up mixed in the same System output.

Figure 9. Two master busses mixing in device

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