為何加入即時口譯後會出現迴音，以及 ParleyVoice 如何在擷取端設計 AEC

A meeting that sounded fine can turn strange once live interpretation is connected: the other side hears repeated speech, freshly played translation is recognized again, and when both people talk at once the level can swing up and down.

The meeting app already has echo cancellation. Why does adding an interpretation tool bring the problem back?

The key is this: interpretation changes where sound comes from and where it goes. Audio processing has to know again which parts are a person speaking and which parts the device has just played.

1. What echo cancellation actually removes

Suppose the other person says a sentence in the meeting. It plays from your computer speakers, is picked up again by a nearby microphone, and is sent back to them.

They hear a slightly delayed version of themselves.

That is classic acoustic echo: played-out sound returns to the microphone through air, desk, and room reflections.¹

Echo cancellation—usually called AEC, for Acoustic Echo Cancellation—estimates and suppresses that played-back echo in the microphone signal while trying to keep the local talker’s voice.

One condition is essential: the system needs to know what the device just played.

Microphone audio may contain your speech, speaker return, and room noise at the same time. If processing also receives a copy of the playback signal, it can use that as a reference to find echo in the mic that correlates with what was played. Capture plus a playback reference are the two critical inputs for this class of processing.²³

2. Why the meeting app’s existing AEC may no longer be enough

In a normal meeting, the app usually controls the audio it receives, plays, and captures. After interpretation is connected, that relationship becomes much more complex.

New translated audio may be outside the original playback reference

For example, the other side speaks English and the meeting app receives English; the interpretation tool generates and plays a new Chinese utterance.

The two clips mean roughly the same thing, but their waveforms, durations, and play times are entirely different.

If the meeting app’s AEC only has the English original as a reference, while your microphone also picks up the loudspeaker Chinese translation, it lacks the reference it needs for that new echo.

Whether this shows up depends on the meeting app, system audio processing, and output devices. When another application plays the new translation, the original processing path may not cover it fully.

The interpretation app may capture the microphone before the meeting app

Two-way interpretation also changes input order: your voice enters the interpretation app first; after translation, it is sent into the meeting through a virtual microphone.

If the first capture already contains loudspeaker translation mixed in, that echo can reach the translation model early. By the time the meeting app receives the translated stream, the content has already changed.

On this path, echo should be handled before audio enters the model whenever possible, so repeated recognition and repeated translation are reduced.

Sound can also loop back on the wrong digital path

Another class of problem is digital audio routing: translation played by an app is captured again by system loopback, or the same virtual cable is used for both input and output so audio returns to the translation inlet.

That feedback never travels through air. Fixing it means clarifying capture scope, input/output direction, and what each play path is for.

So echo after adding interpretation does not mean the meeting app has necessarily failed. More often, new audio paths sit outside the original processing scope. That reading follows from how capture and playback-reference mechanisms work, and from how interpretation is wired in.²³

3. Our design: bring a playback reference in at capture time

For these issues, ParleyVoice’s echo-cancellation design moves processing earlier—to the audio capture stage.⁴

The core idea is straightforward:

When capturing the microphone, also feed the audio that is actually playing as an independent reference into echo cancellation, and suppress loudspeaker return in the mic as much as possible before audio reaches the translation model.

The two inputs have different roles:

“Fed at the same time” means giving the processor both streams. The playback reference stays independent for estimating echo; only the processed microphone speech continues into translation.

The reference should match what is really played

What the model returned is not always identical to what the loudspeaker finally outputs.

Users may lower volume, mute their own interpretation ear-return, or play both the other side’s translation and their own monitor mix. The reference should track final playback content, level, and timing as closely as possible.⁴

If a meeting app plays original remote audio straight to the speakers, that loudspeaker path also needs to be considered for reference coverage. Knowing only what the interpretation app itself played may not be enough for every echo in the room.

Processing must track capture and playback timing

Played sound reaches the microphone after device, air, and room delay, and with level and spectral change.

AEC must keep estimating the loudspeaker’s contribution in the mic and suppress it. A timely, accurate playback reference gives that process better information.²

While playing translation, still try to keep new user speech

Real meetings often involve listening and adding a thought at the same time—for example, speaking up with “one more point” before the translation finishes playing.

So this design is not only about driving echo down; it also aims to keep new speech when playback and talking overlap. Sound quality, double-talk, and behavior across devices still need validation in real use.

4. Acoustic echo and digital feedback both need attention

Capture-side AEC addresses loudspeaker sound returning through the air to the microphone. Alongside that, ParleyVoice also reduces chances that translation re-enters the translation path through routing.

On the Windows system-audio capture path, the app excludes output from its own process tree; dual virtual-cable setups check whether endpoints are reused, and keep “translation to the meeting” separate from “original audio from the meeting.” These are routing guards already present in the current client.⁵

They work with capture-side AEC: the former reduces digital loopback; the latter targets physical playback returning to the mic.

For users, we want a simpler result: when translation plays, the system tries not to treat it as a new utterance again; when the user speaks, their words reach translation clearly.

5. Making clear audio part of live interpretation

A professional interpretation experience needs the model, capture, playback, and audio routing to work together.

Low latency gets translation there sooner; sound echo handling helps the model hear what actually needs translating. Together they improve whether people can listen, speak, and respond naturally.

ParleyVoice is refining audio processing around that goal: let capture know what is really playing, keep echo out of the model where we can, and send each direction of audio to the right place.

We want users to keep their attention on the people in the conversation—and let audio processing do its job quietly.

This article describes the design of capture-side echo cancellation. Full results of related enhancement paths still need validation and refinement by device and audio mode; available capability depends on the version in use.⁴

Learn about ParleyVoice: Overseas parleyvoice.com · China parleyvoice.cn

Technical references

Canonical / original:

• Overseas: https://parleyvoice.com/blog/echo-cancellation-for-meeting-interpretation
• China: https://parleyvoice.cn/blog/echo-cancellation-for-meeting-interpretation

1. Google Workspace: acoustic echo cancellation overview. ↩

2. WebRTC audio processing API: capture stream and reverse (playback) stream. Cited for general audio-processing principles; it does not mean the product uses that project’s specific implementation. ↩

3. Microsoft: capture endpoint and acoustic echo cancellation render endpoint. ↩

4. Product design basis: ParleyVoice release/1024 audio architecture and default-path notes (internal engineering docs; repository links omitted from the public post). This article follows the design; it does not claim every default path is already fully shipped. ↩

5. Windows system-audio capture scope and dual virtual-cable endpoint checks are current client routing guards (internal implementation notes; repository links omitted from the public post). ↩