We work on MeetVoice, a Chrome extension and desktop app for Google Meet. This article explains several design choices in its two-way language-pair mode: separating audio directions, choosing a runtime boundary, controlling playback, and stopping asynchronous work cleanly.

Model the two directions separately

For an English-speaking participant talking to a Ukrainian-speaking participant, the local user's two paths look like this:

Incoming
Meeting audio → recognition → translation → local captions and voice playback

Outgoing
Local microphone → recognition → translation → voice injected into the meeting

The destination changes the behavior. Incoming translation helps the local user understand the meeting. Outgoing translation changes what everyone else hears.

In MeetVoice, the two pipelines share a WebSocket connection, but carry direction information. Each direction has its own source and target language, synthesis work, and playback destination. That distinction also needs to survive errors and cancellation: stopping an incoming phrase should not accidentally target an outgoing reply.

There is a product consequence too. Translating the user's own speech is off by default and must be enabled separately. A successful incoming subtitle is therefore insufficient evidence that a two-way call is ready. Test from the remote participant's side as well: can they actually hear the translated reply?

Give each runtime a clear responsibility

MeetVoice uses both a Chrome extension and an Electron desktop app. The extension handles the meeting-facing work: tab audio, the microphone bridge, captions, and playback integration. The desktop app starts and manages a local server process that coordinates recognition, translation, and speech synthesis.

Within the extension, a dedicated offscreen document owns tab capture and the WebSocket connection. The popup provides controls without owning the long-running capture session. Closing that small interface should not become the lifecycle boundary of the audio pipeline.

These boundaries make ownership explicit, but they also add failure cases. The extension may be installed while the desktop app is stopped. A meeting tab may disappear while background work is still running. Connection state and cleanup belong in the design from the beginning.

A local process also says little about where data is processed. MeetVoice uses cloud services for speech and translation. We need to describe that clearly rather than let users infer offline operation from the presence of a desktop app.

Design the playback graph alongside recognition

Producing translated audio is only part of the job. The system has to play it at the right destination without feeding its own synthetic speech back into recognition.

For incoming translation, the original meeting audio and local translated playback have separate roles. We lower the original audio while the translated voice is audible, then restore it. This is commonly called ducking.

The restoration path deserves as much attention as playback start. A synthesis failure, an interrupted clip, or a stopped session must release the volume adjustment. Otherwise a translation error can leave the rest of the meeting unexpectedly quiet.

Outgoing audio has a different destination: it is injected into the audio path used by the meeting. A local playback test cannot establish that this path works. Use an actual second participant or a separate test device with headphones, and check both what is heard and what happens when the microphone is muted.

Separate readable text from speakable text

Recognition can produce partial hypotheses before a phrase is complete. Text on screen can be revised as more context arrives. Spoken audio cannot be taken back once another participant has heard it.

That gives captions and voice output different timing requirements. A streaming interface can display progress while translation and synthesis still need useful phrase boundaries. Trying to speak every unstable fragment risks producing broken or repeatedly corrected sentences.

When evaluating a pipeline, follow the whole path to audible playback. Recognition time, translation, synthesis, queueing, and playback startup all contribute to the experience. A fast response from one service does not establish the delay the participant actually hears.

Bound the age of queued speech

An audio queue can preserve order while falling further behind the live conversation. Once participants have moved to a new topic, an old translated sentence can arrive at a confusing moment.

MeetVoice has playback lag budgets and cancellation paths for stale speech. The general design question is what to do when a phrase is no longer timely. Queue management needs a policy for dropping work, as well as one for delivering it.

Cancellation has to reach work already in progress. Removing an item from a pending list does not stop an active synthesis request or prevent a late result from arriving. Playback cleanup must still run when that work is aborted.

Treat stopping as a state transition

A live audio feature has several asynchronous owners: capture, recognition, translation, synthesis, transport, and playback. Any one of them can finish after the user stops the session.

MeetVoice uses generation checks to reject work belonging to an earlier session or capture. Stopping also releases capture resources, aborts playback work, and restores audio levels. The checks remain relevant after asynchronous waits, because the session may have changed while a request was in flight.

Useful test scenarios include stopping during synthesis, restarting before an old result returns, closing the meeting tab during playback, and interrupting one direction while the other is active. Each scenario should have an observable outcome: no stale speech in the new session, no abandoned capture, and restored volume.

The central lesson for us is that two-way translation is an audio lifecycle feature as much as a language feature. Define which side receives each output, which component owns it, and how it ends. Those decisions shape whether a translated conversation remains understandable when the network slows down or the user changes their mind mid-sentence.

Writing disclosure: this article was drafted with AI assistance. Its technical descriptions were checked against the current MeetVoice implementation.