A character begins speaking during a combat encounter. The music is at full intensity, the player's weapon is firing, and the enemy has just landed a hit. Without any intervention, the dialogue is buried under three other audio layers, and the player misses the line that explains what they are supposed to do next. Ducking is the mechanism that solves this, and it is one of the few audio techniques that the player never notices when it is working correctly and immediately notices when it is not.
The concept is simple: when one signal is present, reduce the volume of another so the first one is audible. The implementation in games is not simple, because the game mix is event-driven rather than continuous, and the conventional music-production approach to sidechain compression does not map cleanly onto it. This article covers the two mechanisms — continuous sidechain and event-triggered ducking — the parameter ranges that keep the mix from pumping, and the implementation in Wwise and FMOD.
The broader mix structure is covered in the audio mix hierarchy guide, and the voice budget considerations are covered in the sound prioritization guide. This article assumes those systems are in place and focuses specifically on the dynamics processor that sits between them.
Why does music-production sidechain compression not work in games?
In music production, sidechain compression is a continuous process. A compressor on the music bus is triggered by the kick drum signal, and every time the kick hits, the music ducks by a few decibels for a fraction of a second. The effect is rhythmic and predictable, because the kick is rhythmic and predictable.
Game audio is not rhythmic. A dialogue line starts at an arbitrary moment, lasts for an unpredictable duration, and ends without a clear signal that tells the compressor to release. If the same sidechain compressor from music production were applied to the game's dialogue bus, it would duck the music every time the voice crossed the threshold, which happens on every syllable. The music would pump in sync with the speech, which sounds like a bug rather than a feature.
The solution is to split the problem into two mechanisms. The first is a continuous sidechain, used when one signal has a predictable rhythmic character and the compressor can track it. The second is event-triggered ducking, used when the ducking should happen once per logical event — the start of a dialogue line, the beginning of a cutscene — and should be held for the duration of that event without tracking the signal itself.
Most game audio uses the second mechanism. The sidechain compressor is useful in specific cases — ducking the ambience under an engine sound with a rhythmic pulse, for example — but the majority of ducking in games is event-triggered.
What are the parameters that define an event-triggered ducking system?
An event-triggered duck consists of four parameters that determine its behavior. The event itself — the start of the dialogue line, the beginning of the cutscene — is what fires the duck, and the parameters control how the duck behaves once it is fired.
| Parameter | Typical range | Effect |
|---|---|---|
| Depth | -3 to -12 dB | How much the target bus is reduced |
| Attack | 50 to 300 ms | How quickly the duck reaches full depth |
| Hold | Duration of the event | How long the duck stays at full depth |
| Release | 500 to 2000 ms | How quickly the target returns to normal |
Depth is the most important parameter and the one most often set wrong. A depth of -3 dB is barely noticeable and rarely enough to make dialogue audible over combat. A depth of -12 dB is aggressive and starts to feel like the music is disappearing. The range that works for most games is -4 to -8 dB, with -6 dB being a reasonable default. The right value depends on the frequency content of the two signals: if the dialogue is in the mid-range and the music has most of its energy below 200 Hz, a smaller depth is enough. If the two signals overlap in the same frequency range, a deeper duck is needed.
Attack is the time it takes for the duck to reach its full depth. A very short attack — under 50 milliseconds — sounds abrupt and can produce a click on the music. A slow attack — over 300 milliseconds — sounds smooth but means the beginning of the dialogue line is not fully protected. The 50 to 300 millisecond range covers most cases, with the exact value depending on the character of the music. Slow, sustained music can use a slower attack without any artifact; percussive music needs a faster attack to duck before the first beat lands.
Hold is the time the duck stays at full depth. For event-triggered ducking, the hold should match the duration of the event that fired it. A dialogue line that lasts four seconds should hold the duck for four seconds. This is why event-triggered ducking is not a simple compressor — the hold time is not derived from the signal, it is set explicitly by the game logic that knows how long the event will last.
Release is the time it takes for the ducked bus to return to its normal volume after the hold ends. A fast release — under 500 milliseconds — makes the music jump back up, which the player will notice. A slow release — over two seconds — makes the music feel like it is fading back in rather than returning, which is usually the more natural result. The 500 to 2000 millisecond range works for most cases, with the slower end of the range preferred for music and the faster end for short effects.
Where in the signal chain should the ducking live?
Ducking is a bus-to-bus relationship, not a per-sound property. The ducking processor sits on the bus that is being ducked — the music bus, or the ambience bus — and it is triggered by a signal from another bus. This means the audio designer sets up the routing once, and every sound routed to the triggering bus automatically activates the duck.
The routing that works for most games uses three buses in a specific relationship. The dialogue bus sends a sidechain signal to both the music bus and the ambience bus. The music bus and ambience bus each have their own ducking processor configured with their own depth, attack, hold, and release. The dialogue bus itself is not ducked by anything; it is the trigger for the other ducks.
This arrangement means a sound routed to the dialogue bus ducks both the music and the ambience at the same time. The two ducks do not have to be configured identically — the music might duck by -6 dB with a 2000 ms release, and the ambience might duck by -4 dB with a 1000 ms release — because they are separate processors triggered by the same signal. This is where the audio designer's judgment matters most, because the two ducks should feel like one action from the player's perspective, even though they are technically two separate processes.
The ducking should not be applied to the sound effect bus. Sound effects and dialogue are both foreground audio elements, and ducking one under the other would produce a mix where the player cannot tell which is more important. The exception is a specific sound that is clearly dominant — a boss scream, an explosion that is meant to drown out the rest of the mix — and in that case the ducking is configured on the specific sound rather than on the bus.
What are the pitfalls that produce audible ducking artifacts?
The most common artifact is pumping: the music audibly swelling and dropping in sync with the dialogue. Pumping happens when the ducking processor tracks the dialogue signal continuously instead of using an event-triggered hold. The fix is to switch from sidechain compression to event-triggered ducking with an explicit hold time, or to increase the hold time if the event-triggered system is already in use.
The second artifact is stuck ducking: the music stays quiet after the dialogue ends. This happens when the release time is very long — several seconds — and the player triggers a series of dialogue lines in quick succession. Each line extends the hold, and by the time the last line ends, the music has been held down for ten or fifteen seconds. The fix is to cap the hold time regardless of how long the event lasts, and to let the release happen even if a new event fires during the hold. A hold cap of four to six seconds works for most games.
The third artifact is ducking feedback: one duck triggers another. This happens when the dialogue bus sends a sidechain signal to the music bus, the music bus sends a sidechain signal to the ambience bus, and the ambience bus sends a sidechain signal back to the dialogue bus. The result is a mix that oscillates unpredictably as the three buses duck each other in a loop. The fix is to maintain a strict hierarchy: dialogue ducks everything, sound effects duck nothing, ambience ducks nothing, music ducks nothing. Any other arrangement is likely to produce feedback.
The fourth artifact is inaudible ducking: the mix sounds the same whether dialogue is playing or not. This happens when the depth is too shallow — under -2 dB — or when the dialogue itself is not loud enough in the mix. The fix is to raise the dialogue bus level before increasing the duck depth, because a louder dialogue is better than a deeper duck. The duck should be a supporting mechanism, not the primary way the dialogue is made audible.
How is ducking implemented in Wwise?
Wwise provides ducking as a property of the busses in the Audio Mixer Hierarchy. The implementation uses two pieces that work together: the Sidechain Send property on the source bus, and the Ducking property on the target bus.
To set up dialogue ducking in Wwise, the audio designer first selects the Dialogue bus in the Audio Mixer Hierarchy and enables the Sidechain Send property. This makes the dialogue bus a source for ducking signals. Next, the Music bus is selected, and the Ducking property is enabled. Wwise provides four ducking parameters on the Music bus: Duck Volume (the depth in dB), Attack Time, Release Time, and Duck Recovery Time (the hold). The designer sets these values according to the depth and timing described above.
The advantage of Wwise's implementation is that the ducking is applied at the bus level, which means the audio designer can change the depth or timing without modifying any individual sound. The disadvantage is that Wwise does not know when the dialogue line will end, so the hold time must be set to a fixed value rather than to the duration of the specific line. If a game has dialogue lines of very different lengths, the fixed hold time produces either stuck ducking for short lines or insufficient ducking for long lines. The solution is to have the game code adjust the hold time dynamically, which requires a small amount of scripting.
How is ducking implemented in FMOD?
FMOD handles ducking through the Sidechain property on the buses in the mixer. The setup is similar to Wwise: the Dialogue bus is set as the Sidechain Source, and the Music bus has a Sidechain Effect with the depth and timing parameters.
The main difference from Wwise is that FMOD's Sidechain Effect is a component rather than a bus property, which means it can be placed anywhere in the effect chain on the Music bus. This is useful if the ducking should happen before or after another effect — for example, before a compressor that is already on the Music bus, so that the compressor sees the ducked signal rather than the unducked one.
The other difference is that FMOD's Sidechain Effect does not have a separate Hold parameter. The Duck Time parameter combines the attack, hold, and release into a single envelope, and the shape is controlled by the Attack and Release sliders. To achieve an event-triggered duck with a fixed hold time, the game code has to trigger the duck explicitly and then trigger the release explicitly, rather than relying on the Sidechain Effect to handle the timing. This is a smaller implementation change than it sounds, but it requires the audio programmer to be involved.
When is sidechain compression actually the right tool?
Sidechain compression is not the primary ducking mechanism in games, but there are specific cases where it works better than event-triggered ducking. The pattern is that sidechain compression is the right tool when the trigger signal has a clear rhythmic character and the ducking should track it in real time.
The clearest use case is ambience under an engine sound. A vehicle engine has a rhythmic character that the ambience should duck under continuously. The sidechain compressor on the Ambience bus, triggered by the Engine bus, produces a duck that tracks the engine's fluctuations rather than a fixed-depth duck that fires once. The result is an ambience that feels like it is responding to the engine rather than being switched off when the engine starts.
The second use case is music duck under a continuous sound effect. A rushing river, a waterfall, a sustained energy field — these are sounds that have a stable but not perfectly constant level, and sidechain compression produces a duck that matches their fluctuations rather than a fixed-depth duck. The difference is subtle but audible; a fixed-depth duck produces a mix that feels static, while a sidechain duck produces a mix that breathes with the sound.
The third use case is sound effect under sound effect. A weapon impact that should be heard over a footstep, for example, can use sidechain compression on the Footsteps bus, triggered by the Weapon bus. This is not common, because most weapon sounds are short enough that the duck is over before the next footstep, but for sustained weapon sounds — a chainsaw, a beam weapon — it can prevent the footstep from being buried under the continuous weapon sound.
In all three cases, the key is that the trigger signal has a rhythmic character that the compressor can track. When the trigger is dialogue, the compressor cannot track it, and event-triggered ducking is the right mechanism. When the trigger is a sound with a clear rhythm, the compressor produces a more natural result than a fixed-depth duck.
What does a working ducking system sound like?
The most useful test of a ducking system is whether the player notices it. A working ducking system is invisible: the player hears the dialogue, the music is audible, and nothing in the mix sounds like it is being adjusted. A failing ducking system is obvious: the music pumps, or the dialogue is buried, or the mix has a rhythmic swell that does not correspond to anything in the game.
A useful diagnostic is to play the game with the music muted and then unmuted, listening to the same sequence of dialogue events. If the music comes back at the same level each time the dialogue ends, the release time is consistent. If the music comes back higher than it was before the dialogue, the duck is not restoring the original level. If the music does not come back at all, the duck is stuck. Each of those symptoms points to a specific parameter that needs adjustment.
The second diagnostic is to listen to a dialogue line that plays over loud combat. The dialogue should be audible without the music having to disappear entirely. If the music is inaudible during the line, the duck is too deep. If the dialogue is inaudible, the duck is too shallow. The correct balance is usually found by setting the dialogue bus level first, then adjusting the duck depth to the minimum value that makes the dialogue comfortable to listen to.
The third diagnostic is to listen to the transition between dialogue and silence. The music should not have a perceptible swell as the duck engages or releases. If the music rises noticeably when the dialogue ends, the release time is too short. If the music drops noticeably when the dialogue begins, the attack time is too short. Both problems are solved by lengthening the corresponding parameter, usually to the slower end of the ranges given earlier in this article.
The final consideration is that ducking is a supporting mechanism, not a primary tool. If the dialogue is not audible without ducking, the problem is not the duck — it is the dialogue level, the frequency content of the dialogue, or the overall mix balance. Ducking works best when the dialogue is already close to audible, and the duck provides the last few decibels of separation that make the line comfortable rather than a struggle. If the duck has to be deep enough to eliminate the music in order for the dialogue to be heard, the mix has a structural problem that a duck cannot solve.
Create Dialogue-Layer Source Material
Open the SfxMaker generator and create the non-voice sound effects that compete with dialogue in the mix — UI feedback, weapon impacts, footsteps. Dialogue ducking is most effective when these supporting sounds are already level-matched, and generating them from the same tool with consistent normalization makes that matching easier.
Open SfxMaker Generator →