DEV Community: Parley

How Real-Time Simultaneous Interpretation Works: Pipeline vs End-to-End Speech Models

Parley — Mon, 26 Oct 2026 02:05:45 +0000

Short answer: “Realtime voice translation” usually means one of two architectures. A three-stage pipeline turns speech into text (ASR), translates the text (MT), then speaks the result (TTS). An end-to-end / speech-to-speech (S2S) system maps speech toward speech more directly, with less (or no) intermediate text you can inspect. Latency, fidelity, language coverage, voice cloning, and cost all follow from that choice — not from marketing labels.

I built Parley Voice (China: parleyvoice.cn) because I sit in international meetings, my spoken English is weak, and I wanted two-way spoken translation through Zoom, Google Meet and similar apps without asking the other side to install anything. Disclosure: I make Parley. This piece is the architecture trade-off I wish someone had written before I started shipping.

What “three-stage” means (ASR → MT → TTS)

Cascaded systems do three jobs in sequence:

ASR — turn source audio into text.
MT — translate that text into the target language.
TTS — synthesize speech from the translated text (system voice or cloning).

Buffers and phrase-boundary logic sit between stages. That is why cascades often feel like sitting next to a human interpreter: they wait a beat for context, then emit a chunk.

Strengths: inspectable intermediate text (captions, logs, SRT); independent knobs for ASR / MT / TTS; familiar failure modes (“the transcript misheard the name”).

Costs: stacked delay; error compounding (ASR miss → wrong MT → confident TTS); prosody loss unless cloning or style transfer is added.

What “end-to-end / S2S” means

End-to-end (often marketed as speech-to-speech or S2S) tries to go from source audio toward target audio with fewer hand-offs. Designs vary: a single model emitting translated speech or speech tokens; a shared latent space; or hybrids that peek at text internally without exposing a clean ASR→MT→TTS product surface.

For buyers, the practical definition is: you hear translated speech, and you may or may not get a reliable intermediate transcript as a first-class feature.

Strengths: fewer hand-offs can reduce stacked error and, in some demos, feel more continuous; prosody may transfer better when speech is modeled jointly.

Costs: harder to debug without a stable text stage; language matrices are often narrower than cascaded ASR/MT catalogs; caption quality is not guaranteed; you may lose independent cost/control over each stage.

Neither architecture is “more simultaneous.” Simultaneous means overlapping in time with the speaker — not zero delay. Both buffer audio for context.

Latency, fidelity, languages, voice, and cost

Latency

Published figures are easy to misuse. On Parley’s live site (as of 2026-10-22), Qwen officially reports LAAL of about 2.3 s, and Doubao reports speech output latency of about 2.53 s. The site is explicit: these are different metrics — not a direct speed comparison or a guarantee of in-app latency. Actual delay depends on the model, network, and audio devices. Provider demos are not Parley app recordings.

Ask vendors: is the number model-only or full path (capture → cloud → playback)? Does silence while connected count toward billing? Did you measure on your network before an important call?

Fidelity

Cascades fail when ASR mishears; E2E fails when the joint model drifts. Mitigation is the same: pause on numbers and names, confirm commitments, keep captions as a second channel when available. For legal, safety, or contractual content, use a qualified human interpreter when the risk requires it.

Language coverage

Input recognition and spoken output are not the same list. On Parley’s live languages (China) page:

Model	Input	Spoken output
Qwen (multilingual)	60 languages	29 languages (Cantonese is input-only)
Doubao	Chinese ↔ English	Chinese ↔ English

OpenAI and Gemini adapters are marked coming soon on the live site — not available in the app’s provider selector today.

Cascaded stacks often win breadth by composing ASR/MT catalogs. E2E stacks often win continuity on fewer pairs. Check spoken targets, not “supports 100 languages” headlines.

Voice cloning

Voice answers “what should the translation sound like?” — not which architecture is used. On Parley’s managed service, Qwen and Doubao currently support live voice cloning at the displayed session rate: no advance sample or enrollment (per live FAQ / homepage). You can also pick a built-in voice. Likeness is not a guarantee of translation accuracy. Deeper note: Meeting translation in your own voice (China).

Cost knobs

As of the live pricing page (China): managed Qwen $0.070 / minute, managed Doubao $0.148 / minute, no recurring Parley subscription for managed meeting use, billed by the millisecond once the connection is ready (silence included; stop the session to stop billing). Two directions share one session charge. A 60-minute Qwen session at list rates is $4.200; Doubao is $8.880. Temporary Preview offers can change what you pay for credit — check the live page. The homepage still states a $1 first top-up is enough to try.

When each fits meetings vs venues

This is different from choosing meeting voice vs captions vs venue mode (Live voice, captions and venue interpretation (China)). Here the question is pipeline style inside the speech path.

Online meetings (two-way): you need speak + listen, turn-taking, and often captions for verification. A cascade that exposes bilingual text is usually easier day to day. An E2E model can feel smoother in demos only if captions, language pairs, and virtual-mic routing still work with your meeting app.

Venue / one-speaker events: continuity and clear output routing matter more than back-and-forth repair. Either architecture can work; physical audio (feedback into the source mic, language bleed) often dominates. Architecture alone will not fix a bad PA layout.

Buyer checklist: (1) spoken output languages you need, (2) captions you can re-check, (3) what is billed and whether silence counts, (4) whether the other side must install anything, (5) a real both-directions test before the important call.

Where Parley sits today

Parley is a Windows and Mac desktop app for live meeting translation (China): your mic → cloud translation → virtual microphone into Zoom / Meet / similar; meeting audio → translation → your headphones; bilingual captions in the app; caption history local with SRT export. Only you install it. Managed models shipping now are Qwen and Doubao, with live voice cloning included at the session rate. Gemini and OpenAI are listed as coming soon — not shipped.

I will not invent a roadmap about whether our cloud providers are “pure cascade” or “pure S2S” under the hood. Users feel the product surface — delay, captions, language matrix, voice, and price — more than the research label. We expose managed models with clear per-minute rates, bilingual captions, and honest caveats about network and devices. Delay is often on the order of a couple of seconds in practice (like sitting next to a human interpreter); we do not promise a fixed app SLA.

Try a short session

Download Parley for Windows (x64 / ARM64) or Mac (Apple Silicon / Intel).
Check both audio directions with the meeting app you actually use.
Top up — the live homepage still says a $1 first top-up is enough to try — and run a few minutes at pricing (China) rates for Qwen or Doubao.
Stop the session on breaks; connected silence is billed.

Questions: support@awiki.ai.

Disclosure: I am Gaowei Chang, founder of Parley Voice (parleyvoice.com · parleyvoice.cn). I built the product described here. This is not an independent review. Features and prices reflect the public site; confirm /pricing and /languages before you buy.

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

Canonical / original:

Also ZH:

Official posts (both domains):

Also ZH:

Why Meetings Get Echo After You Add Live Interpretation—and How ParleyVoice Designs Capture-Side AEC

Parley — Sun, 25 Oct 2026 03:35:58 +0000

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:

Input	Role in echo cancellation
Microphone capture	The signal to process—may contain local speech, playback echo, and ambient noise
Audio actually playing	An independent reference that helps identify components that came from the loudspeaker

“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:

Google Workspace: acoustic echo cancellation overview. ↩
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. ↩
Microsoft: capture endpoint and acoustic echo cancellation render endpoint. ↩
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. ↩
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). ↩

Keeping Interpretation in Step with Conversation: How ParleyVoice Uses RTC to Cut Waiting in Live Translation

Parley — Sun, 25 Oct 2026 03:35:08 +0000

You have just answered a question on a cross-border call, but the other side does not reply. You assume they missed it and repeat yourself; at the same moment they finally hear the previous translation and start speaking.

What should have been a natural exchange turns into waiting, repetition, and people talking over each other.

That is one of the biggest experience gaps between live interpretation and ordinary text translation: a sentence must not only be accurate—it also has to show up in the conversation on time.

To cut waiting outside the model itself, ParleyVoice introduces real-time audio transport on RTC-supported hosted meeting paths, and coordinates the rhythm of capture, send, and playback. We want interpretation to stay as close as possible to the model’s own response speed, so technical handling takes a little less of the conversation’s time.¹

1. Why latency matters so much

In a meeting, people are not only trading sentences. They are also judging when to reply, when to explain, and when to stop and listen.

If the translation arrives too late, you may still be hearing the previous line while the other person has already moved to the next question. Both sides wait, yet neither is sure the other heard them; a short follow-up is easy to mistime.

Latency during continuous speech hurts understanding as well. The speaker has already flipped to the next slide while the translation in your ear is still on the previous one, so listeners must spend extra effort remapping sound to what they see.

Lower latency therefore has concrete value: easier timely replies, less repetition and interruption, and a better chance of staying with the meeting’s pace.

2. Where time goes from speech to hearing the translation

When people talk about AI translation latency, they often think first of the model. In practice, the model is only one stage in the full audio path.

After sound enters the microphone, it must be captured and packed into frames, sent over the network to the translation service; once the model understands the meaning and produces translated audio, that audio must return to the device, pass through playback buffering, and finally come out of headphones or speakers.

The main waits can be summarized as:

End-to-end interpretation latency ≈ capture and packetization wait + uplink/downlink transport and service forwarding + model understanding and generation + playback buffering and device output.

“Model understanding and generation” also includes waiting the model needs for enough context. With speech-to-speech models, that work may happen inside a single streaming model rather than three separate “recognize → translate → synthesize” services in series.

A faster model clearly helps. But if audio keeps queuing in transport and playback, users will still feel slow.

For example, packets may wait once for transport, wait again on the server to be assembled, then accumulate again on the device before play. Each step adds only a little; together they become a noticeable pause.

Network jitter also makes these waits uneven. Live interpretation therefore needs both low delay and a continuous, stable flow of audio.

3. What is RTC, and why does it fit live interpretation?

RTC stands for Real-Time Communication. Voice calls and video meetings are its most familiar uses.

It organizes the audio path around a clear goal: get sound there in time and keep it continuous, so people can talk naturally.

That matches live interpretation closely. In practice it helps in three ways.

1. Keep audio moving forward in small chunks

Live interpretation needs capture, send, model processing, and playback to advance in parallel as much as possible. As soon as a short chunk is captured, it can start moving downstream; as soon as the model produces playable translation, later stages can receive and play it step by step.

RTC provides transport and playback mechanisms built for continuous audio, reducing the need to repeatedly accumulate large buffers in every application layer.

WebSockets can also stream audio. RTC’s added value is that it folds timing requirements, network adaptation, and playback continuity into the design of the whole path.

2. Reduce extra waiting caused by packet loss

With common reliable, ordered TCP delivery, if an earlier packet must be retransmitted, later packets that have already arrived may still have to wait. That is called head-of-line blocking. In a live conversation, it shows up as an extra pause.²

RTC audio usually prefers transports suited to real-time media, together with error recovery and packet-loss concealment, balancing sound quality against playback deadlines and lowering the chance that a brief network blip stalls following speech. Actual results depend on network conditions and the concrete implementation.²³

3. Control buffering to balance continuity and timeliness

Audio packets on the internet do not arrive at a perfectly even rate. Sometimes they come early, sometimes late; the receiver needs a short buffer to keep sound continuous.

Too little buffering and audio glitches; too much and waiting grows. Mature RTC audio processing adjusts playback buffering to arrival patterns, trading only the wait that is needed for continuous sound.³

For meeting interpretation, that means we pursue faster response while also caring whether a conversation can keep a stable rhythm throughout.

4. How ParleyVoice applies these optimizations to interpretation

On RTC-supported hosted meeting modes, ParleyVoice hands audio transport between the client and the translation service to a real-time media path, while also tuning how audio enters the model and returns to the device.¹

First, keep audio flowing. Captured sound enters the path as continuous small frames, and returned translation advances in segments, reducing unnecessary whole-chunk waits.

Second, keep send cadence aligned with capture cadence. If every send stacks its processing time before the next send, sustained input can gradually back up. We adjusted the send clock so normal processing overhead stays inside the intended period where possible, lowering the risk that audio falls further behind as the conversation continues.

At the same time, control wait on the playback side. After translation enters the play queue, the system keeps a short buffer for coherent playback and limits later queue growth, so different stages do not each add start-of-play delay again.¹

Together, these steps serve one goal: audio the model can already process in time should reach the user’s ear as soon as possible.

5. How low can latency go?

The experience we aim for can be put in one sentence:

Keep end-to-end live-interpretation latency as close as possible to the model’s own response latency, plus a short overhead for audio transport and playback.

That “short overhead” can be thought of at the scale of a few hundred milliseconds of RTC audio capability.

Public RTC technical documentation cites a typical audio-path latency of 150–300 milliseconds—about 0.15–0.3 seconds—covering capture, encoding, network transport, decoding, and playback.⁴

That figure shows that communication and audio processing can occupy only a modest share of overall wait, so interpretation speed depends more on the model’s semantic understanding and speech generation.

It is important to read this accurately: 150–300 milliseconds is a typical path reference from public technical material, not a measured guarantee for ParleyVoice’s full translation chain. Our real path still includes model integration, packetization, and application playback buffering; experience also varies with network, model, device, and usage mode.¹

The direction of RTC optimization is clear: steadily reduce the waiting that can be cut outside the model. The faster the model, the more directly users feel that speed.

For ParleyVoice, low latency finally shows up in real conversation: customer questions get answers sooner, follow-ups in a meeting are easier to attach, and interpreted speech in a talk stays closer to the speaker’s pace.

We want every cross-language exchange to spend a little less time waiting—and a little more time feeling natural.

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

Technical references

Canonical / original:

Product implementation basis: RTC main path, send cadence, and playback buffering notes in ParleyVoice release/1024 (internal engineering docs; repository links omitted from the public post). ↩
IETF RFC 8835: Transports for WebRTC, which discusses TCP vs UDP, network fallback, and head-of-line blocking. ↩
WebRTC NetEq: audio jitter buffer and packet-loss concealment. Cited for general RTC principles; it does not mean ParleyVoice developed or directly ships every module described there. ↩
RTC official technical documentation: end-to-end latency breakdown, page last updated 2026-07-21. The 150–300 ms figure is that document’s typical RTC value for conversational AI scenarios; it illustrates technical scale and is not a commitment for other architectures or all network conditions. ↩

Putting a Live Interpreter Inside Any Meeting App: Lessons from Routing Translated Speech on macOS and Windows

Parley — Sun, 11 Oct 2026 23:44:58 +0000

I built Parley, a desktop live interpreter, because I join a lot of international meetings and my English isn't great. This post is about the audio plumbing, which turned out to be most of the work. No code to sell you here, just what I learned.

The constraint that shapes everything

I wanted spoken translation in both directions during a normal call, without asking anyone else to install anything, and without writing a plugin for each meeting platform.

The only interface every meeting app shares is: it picks a microphone and a speaker. So the interpreter has to be a microphone and a speaker, and sit between the user's real devices and the meeting:

Outgoing: physical mic → capture → cloud translation → translated speech → virtual mic → meeting app
Incoming: meeting app → capture → cloud translation → translated speech → physical headphones

That simple picture hides most of the hard parts.

1. Getting audio into the meeting

The meeting app needs a microphone it can select that carries the translated speech.

macOS. The app installs a virtual audio driver that exposes two devices: ParleyVirtualMic, which the meeting uses as its microphone, and ParleyMeetingBus, which the meeting uses as its speaker so Parley can capture what the other side says. The user's real mic and headphones are selected inside Parley.
Windows 11. The installer bundles the signed VB-CABLE driver. Translated speech goes into the cable; the meeting app selects CABLE Output as its microphone.

Installing an audio driver is the most intimidating step for non-technical users, so I spent a lot of effort on doing it automatically and explaining it in plain language. On Windows the installer now discovers the endpoints itself, with no driver downloads or device IDs to type.

2. Getting audio out of the meeting, and only the meeting

For the listening direction, you want the other participants' voices and nothing else: not your music, not a YouTube tab, not notification sounds.

On macOS, routing the meeting's speaker to ParleyMeetingBus gives Parley exactly the meeting's output.
On Windows, Parley captures the meeting app's process directly, so the user picks "Zoom" (or whichever app) as the listening source instead of all system audio.

A privacy note I put in the docs because it matters: if you capture system audio rather than one process, you may capture more than the conversation you meant to translate.

3. Feedback loops are the number-one failure

If translated speech plays through laptop speakers, the mic hears it, translates it again, and you get an echo chamber in two languages. Rules I ended up enforcing in the UX:

Headphones are strongly recommended in meeting mode, and the first-run flow says so.
The meeting only ever hears the virtual mic, never the physical mic directly.
In in-person (venue) mode, where translated speech does go to room speakers, the setup guide tells you to keep the microphone away from them.

4. Streaming and the latency/stability trade-off

Capture is resampled to 16 kHz mono PCM and streamed to the realtime model in ~100 ms chunks. The models are the part I don't build: Parley is powered by state-of-the-art large language models, and today the managed options are Qwen (60 input / 29 spoken output languages, Cantonese input-only) and Doubao (Chinese ↔ English), both with live voice cloning. I don't wait for the user to finish a sentence; the model's own turn detection decides when to speak. Translated audio is decoded and queued for playback as soon as each delta arrives.

The interesting decision was the playback buffer. A short pre-buffer lowers delay but stutters when the network hiccups or the model emits short fragments. I experimented with ~200 ms and went back to about one second, because choppy translated speech is worse for comprehension than a slightly later start. Most of the delay people feel is still the model's: Qwen reports about 2.3 s LAAL and Doubao about 2.53 s speech output latency in their own evaluations (different metrics, not directly comparable).

5. Devices change mid-call

Bluetooth headphones disconnect, sample rates change when you plug in a USB mic, the OS switches default devices. Each of those can silently kill one direction. The audio layer (built on cubeb, in Rust) has to notice, reopen the device, and keep the session alive, while the UI (Slint) tells the user what happened instead of just going quiet.

6. Letting you hear your own translation

Once the outgoing direction worked, the obvious question from my own calls was: what did they actually hear? So the meeting bar has a translated voice monitor. It plays the model's translated output of what you said into your own headphones. It never plays your raw microphone, and it doesn't open a second model session.

A few rules kept it from breaking anything else:

It's an optional branch at the point where translated speech leaves the model. The full stream still goes to the virtual mic; the monitor copy goes through its own bounded queue, and if that queue backs up it drops its own stale audio rather than slowing the meeting mic.
It's mixed into the one output stream Parley already has open to your headphones. No ducking, no automatic volume changes to the meeting audio, and a soft knee near full scale instead of hard clipping.
The volume control (0–100%, default 15%, on a perceptual curve) changes only the monitor's gain. It never touches the system/device volume, the meeting audio, or what's sent to the meeting. Gain changes ramp over a few milliseconds to avoid clicks, and off or 0% is bit-exact bypass.
Gating follows the translated samples, not your mic, so a translation that arrives after you stop talking isn't cut off.
It's still not echo cancellation: if you use speakers, the mic can pick them up. Headphones remain the rule.

7. One input, many outputs

The venue mode was a nice generalisation: one speaker, several languages at once, each language sent to its own physical speaker or headphone output with its own playback queue (a single output works too). It's unlocked by a one-time $149 venue licence, then billed by usage like everything else. Captions are grouped by language in the history, and SRT export covers the whole session.

8. Billing that matches what users expect

People don't think in "streams". They think "my meeting lasted 30 minutes". So a two-way meeting, or a venue session with three languages, is one session charge: billing counts the connected time once (by the millisecond, from when the connection is ready, silence included), not once per direction or output. Short sessions aren't rounded up to a full minute. There's no software to buy and no subscription for meeting translation; you pay per minute from a wallet. It complicated the server side, but it makes the price explainable in one sentence.

What I'd tell anyone building something similar

Design the first-run audio setup before you design anything else.
Treat feedback prevention as a product feature, not a bug fix.
Pick buffer sizes for intelligibility, not benchmark latency.
Expect device changes constantly and make recovery visible.
Price in the unit users think in.

Disclosure: I'm the founder of Parley. Parley runs on macOS 14.5+ and Windows 11 x64.