A translated voice is hard to follow when the original speaker is just as loud. Turning up the translation can make the mix tiring. Muting the original removes useful context, including the speaker's tone and pauses.
Audio ducking lowers the original sound while the translated voice plays. The idea is straightforward. The routing needs more care: lowering what the listener hears should not lower the audio sent to the translation model.
Separate capture from playback
In WireLang™'s browser implementation, captured tab audio splits into separate paths. One sends audio to the listener through a volume control. Another extracts audio for translation. The returning translated voice has its own playback volume.
That separation matters. If the capture path followed the listener's volume slider, turning down the original could also weaken the speech sent for translation. Keep the capture signal independent of the listening mix.
Use the playback clock
Receiving a translation chunk and hearing it are different events. A chunk may wait behind audio already queued for playback. Restoring the source volume as soon as a network message finishes can bring the original voice back while the translation is still speaking.
WireLang's browser implementation tracks active playback nodes. It restores the source level after the last node ends, and also restores it when the queue is cleared. This ties volume recovery to the playback queue.
The implementation ramps the source down over 100 milliseconds and restores it over one second. During ducking, it uses 20% of the selected source level. These are implementation values, not measured recommendations for every voice or listening environment.
Desktop capture changes the problem
A browser tab gives the application a defined audio source. Desktop capture has to account for the operating system, audio devices, and the translator's own output. Feeding the translated voice back into capture can create a translation loop.
The macOS helper in WireLang's source has two backends. Its Core Audio process-tap backend is designed to keep full-level audio for capture while playing the source at a lower level. The ScreenCaptureKit fallback reports that ducking is unavailable. A working capture stream does not, by itself, mean ducking is supported.
These notes describe the inspected source implementations. Backend selection and support depend on the build and operating system. Windows audio routing needs its own implementation and validation.
What to check before shipping
Listen through a complete sentence, a pause, and an interruption. Check that the source returns to the selected level after playback ends. Then stop mid-sentence, disconnect the session, and change the output device. Each case should leave the user with usable audio.
Also check the captured signal while changing source volume. The listener's level should change without attenuating the input used for translation. Test for recapture of the translated voice separately; a comfortable listening mix can still hide a routing problem.
If you are using WireLang
Start with headphones and a low original volume. Raise the source until you can hear enough of the speaker to follow their tone. Adjust the translated voice separately. If several apps are speaking, mute the unrelated ones or select a single source app where available.
If the original sound does not get quieter, check which controls your platform and build support. Raising the translated voice to maximum may make both voices louder without making either easier to understand.
For the full setup, follow How to translate live audio from your PC. The tutorial shows the floating toolbar and volume controls.
Implementation note: this article was drafted with AI assistance and checked against WireLang's browser playback code and macOS capture helper. It does not report a latency benchmark or a listening study.