DEV Community: Oleksii “Alex” Herasymchuk

Why my real-time Google Meet translator runs on your laptop, not my server

Oleksii “Alex” Herasymchuk — Mon, 20 Apr 2026 11:40:10 +0000

$0/month in infra costs. Audio that never leaves the user's device. Real-time two-way voice translation in Google Meet. Here's the architecture trick that made all three possible at the same time.

I built a Chrome extension that does real-time, two-way voice translation in Google Meet. You speak Russian, your colleague hears English. They reply in German, you hear Russian. Subtitles, TTS, the whole thing.

Then I had to figure out how to ship it.

Most "AI in your meeting" tools follow the same playbook: the client streams mic audio to a backend, the backend pays for STT + LLM + TTS, and the user pays a subscription that hopefully covers the bill plus some. That model has two problems I didn't want:

Every minute of conversation is a row in my AWS bill, and I have no upside on heavy users.
Every minute of conversation is also someone else's microphone going through my server. That's a privacy story I didn't want to maintain.

So MeetVoice ships a different way.

The pivot: BYOK + a desktop app

The architecture is two things you don't usually combine:

Bring-your-own-key (BYOK): users plug in their own Deepgram + Groq + (optional) OpenAI keys. Free-tier Edge TTS as default — Microsoft pays for that one (unofficial endpoint, but it's been stable for years).
The "server" runs on the user's laptop. I ship a small Electron tray app for Windows and macOS that boots a local WebSocket server on 127.0.0.1:18900. The Chrome extension connects to it.

What I get:

Zero infra cost. No EC2, no Cloud Run, no serverless cold starts. My recurring infra bill is one Cloudflare Worker for the marketing site.
Audio never leaves the device (modulo the user's chosen STT provider, which is on their key — and they picked it).
Scaling is free. New user = new laptop = new server.

What I trade away:

Onboarding is harder. "Download an app" is more friction than "install extension and sign in."
I can't auto-update server-side bug fixes without an electron-updater roundtrip (R2 + electron-updater handles this fine, but it's another moving part).
Licensing has to live on the desktop side (LemonSqueezy + a tiny Cloudflare Worker for entitlement checks).

For an indie SaaS, that tradeoff is a no-brainer. Now let me show you the technically interesting part.

The pipeline

Mic / Tab audio
   │
   ▼
Deepgram Nova-3 (streaming WebSocket, diarization)
   │
   ▼
TranscriptBuffer (sentence boundary + speaker change + 4s safety timeout)
   │
   ▼
Groq Llama 3.3 70B (streaming, sentence-chunked translation)
   │
   ▼
Edge TTS (free, Microsoft Neural voices)
   │
   ▼
Audio injection back into Meet

Two of these run in parallel per call:

Incoming pipeline (peerLang → userLang): tab audio → translated voice played through your speakers, plus subtitles.
Outgoing pipeline (userLang → peerLang): your mic → translated voice spoken into the meeting as if you said it, plus subtitles for the other side.

Both pipelines share one WebSocket. I multiplex direction with a prefix byte (0x00 incoming, 0x01 outgoing). Cheap, schemaless, works.

End-to-end latency is around 1.5–2 seconds in the steady state. Most of it is Deepgram waiting to confidently mark a chunk is_final.

Now the two parts that took the longest to get right.

Hack #1: hijacking getUserMedia to inject TTS into Meet

This is the cool one.

When Meet wants your microphone, it calls navigator.mediaDevices.getUserMedia({ audio: true }). It gets back a MediaStream, and that's what flows to the other participants.

So I just... return a different stream.

// content script, world: "MAIN", runAt: "document_start"
const origGetUserMedia = navigator.mediaDevices.getUserMedia
  .bind(navigator.mediaDevices);

navigator.mediaDevices.getUserMedia = async (constraints) => {
  if (!constraints?.audio) return origGetUserMedia(constraints);

  // Get the real mic, but don't hand it to Meet directly
  const realStream = await origGetUserMedia(constraints);

  // Build a controllable stream Meet will hold a reference to
  const controlStream = new MediaStream();
  for (const t of realStream.getAudioTracks()) controlStream.addTrack(t);
  for (const t of realStream.getVideoTracks()) controlStream.addTrack(t);

  // After the next user gesture, swap the audio tracks for our mixed stream
  document.addEventListener("click", trySetupGraph, true);
  return controlStream;
};

The mixed stream is built with Web Audio:

audioCtx     = new AudioContext({ sampleRate: 48000 });
destination  = audioCtx.createMediaStreamDestination();
micSource    = audioCtx.createMediaStreamSource(realStream);
micGainNode  = audioCtx.createGain();   // mic, with ducking
ttsGainNode  = audioCtx.createGain();   // injected TTS, with boost

micSource.connect(micGainNode).connect(destination);
ttsGainNode.connect(destination);

// Swap tracks on the stream Meet is already holding a reference to
for (const t of controlStream.getAudioTracks()) controlStream.removeTrack(t);
for (const t of destination.stream.getAudioTracks()) controlStream.addTrack(t);

When the server sends translated TTS audio back:

Decode the chunks into an AudioBuffer.
Duck micGainNode to 20%, so you don't talk over yourself.
Play the buffer through ttsGainNode → destination.
On source.onended, restore the mic gain.

From the other participants' point of view, they hear you speaking their language. Their Meet client doesn't know there's a synthesised voice in the pipe — it's just bytes on the same MediaStream Meet asked for.

A few things that bit me:

AudioContext needs a user gesture to start in the running state. So getUserMedia returns the real stream first, and the swap happens on the next click/keydown. Skip this and Chrome creates the context in suspended state — silent failure mode where nothing throws but no audio flows.
The override script runs in the MAIN world, which means no chrome.* APIs. All extension communication goes through window.postMessage with targetOrigin: "https://meet.google.com" (never "*" — defense-in-depth).
A sequential TTS queue is mandatory. Two segments arriving back-to-back and decoded in parallel will overlap and sound like two drunk synths arguing. A single isPlaying flag plus playNext() in source.onended is enough.
A monotonic activePlaybackId counter, bumped on every new playback. Stale onended callbacks from a previous segment check it and bail out. Without this, a fast-arriving newer segment got its mic gain restored by an older callback and the next one started full-volume.

Hack #2: streaming translations without choppy TTS

Deepgram emits two kinds of finalized transcripts: is_final (this chunk is locked in) and speech_final (the speaker just took a breath). If you translate every is_final chunk you get garbage — three-word fragments, no context, awful cache behavior. If you wait for speech_final you get clean translations but the user waits 2+ seconds before hearing anything.

The compromise is a TranscriptBuffer that flushes on whichever happens first:

push(text, speaker, endTime) {
  // Speaker switched — flush the previous speaker first
  if (speaker !== this.speaker && this.segments.length) this.flush();

  this.segments.push(text);
  const accumulated = this.segments.join(" ");

  if (SENTENCE_BOUNDARY_RE.test(accumulated) && accumulated.length > 20) {
    this.flush();                                          // sentence done
  } else if (wordCount(accumulated) >= 30) {
    this.flush();                                          // long monologue
  } else if (!this.timer) {
    this.timer = setTimeout(() => this.flush(), 4000);     // silence safety
  }
}

On the translation side: instead of waiting for the LLM to finish the whole sentence, the Groq response is streamed and re-chunked by sentence (regex [.!?] after 20+ chars). Each sentence is sent to TTS as soon as it lands, not at end-of-stream. This pipelines TTS synthesis on top of LLM generation — first audible word arrives noticeably faster than the naive "translate, then synthesize" loop.

Subtitles update on the interim transcripts (so the user sees them live), but TTS only plays on stable sentences. Best of both.

Stack rundown

Deepgram Nova-3 — only streaming STT I tried that handles speaker diarization well in noisy meetings.
Groq + Llama 3.3 70B — fastest LLM I can afford for a BYOK product. Cheaper per token than GPT-4o-mini and a few times higher throughput. OpenAI is the fallback.
Edge TTS (msedge-tts, MIT-licensed) — Microsoft's Neural voices, free, sound great. OpenAI tts-1 is an optional upgrade.
WXT — best WebExtension framework I've used. Manifest V3, Vite, TypeScript, content-script worlds, all just work.
Electron 41 with an ESM tray app — surprisingly clean. utilityProcess runs the WS server in a child process so it can crash without taking the tray with it.
Astro 6 for the marketing site — static, fast, file-based i18n.

What I rejected:

OpenAI Whisper API — the standard /v1/audio/transcriptions endpoint takes a finished file, not a stream. (The newer Realtime API with gpt-4o-transcribe exists, but it's a different beast and came too late for this design.)
ElevenLabs — beautiful voices, but the per-minute price would make BYOK unaffordable for daily users.
A traditional VPS backend — the entire point of this design.

Three things I'd tell past me

BYOK + local server is a real pattern. Cost-of-revenue collapses to $0. Privacy goes from a marketing line to an architecture property. The price you pay is onboarding friction — and most pro users will gladly trade that for control.
Manifest V3 is harder than the docs admit. You can't keep state in the service worker. You need an offscreen document for anything stateful (audio, persistent WebSocket). chrome.storage is not available in the offscreen doc, so you message-pass with retry. Plan for it.
Electron is not as bad as Twitter says. A tray-only app is ~200 MB on disk and ~80 MB RAM idle. electron-builder handles signing on Mac/Windows. GitHub Actions builds the macOS DMG on macos-latest for free.

If you want to try the thing: download MeetVoice for Windows or macOS at meetvoice.app and install the Chrome extension. You'll need a Deepgram key (free tier is enough to test); the rest is optional.

Happy to answer questions in the comments — especially about the audio graph or the MV3 offscreen-doc dance. Those took the most pain to figure out.

Russian version: На русском

Почему мой real-time переводчик для Google Meet работает у вас на ноутбуке, а не на моём сервере

Oleksii “Alex” Herasymchuk — Mon, 20 Apr 2026 11:36:26 +0000

$0/месяц на инфраструктуру. Аудио, которое не покидает устройство пользователя. Real-time двусторонний голосовой перевод в Google Meet. Вот архитектурный трюк, который позволил совместить всё это сразу.

Я сделал Chrome-расширение, которое в реальном времени двусторонне переводит голос в Google Meet. Вы говорите по-русски — собеседник слышит английский. Он отвечает по-немецки — вы слышите русский. Субтитры, TTS, всё как полагается.

Потом надо было решить, как это шипить.

Большинство «AI в созвонах» работают по одной схеме: клиент стримит микрофон на бэкенд, бэкенд платит за STT + LLM + TTS, пользователь платит подписку, которая (надеемся) покрывает счёт и оставляет маржу. Меня в этой модели не устраивали две вещи:

Каждая минута разговора — это строчка в моём AWS-биле, и у меня нет апсайда от тяжёлых пользователей.
Каждая минута разговора — это ещё и чужой микрофон, проходящий через мой сервер. Privacy story, которую мне не хотелось поддерживать.

Поэтому MeetVoice шипится иначе.

Поворот: BYOK + десктопное приложение

Архитектура — это две штуки, которые обычно вместе не встречаются:

Bring-your-own-key (BYOK): пользователь подключает свои ключи Deepgram + Groq + (опционально) OpenAI. По дефолту бесплатный Edge TTS — за этот платит Microsoft (через недокументированный endpoint, но он стабильно работает уже несколько лет).
«Сервер» крутится у пользователя на ноутбуке. Я поставляю маленькое Electron tray-приложение под Windows и macOS, которое поднимает локальный WebSocket-сервер на 127.0.0.1:18900. Расширение коннектится к нему.

Что я с этого получаю:

Ноль инфраструктурных затрат. Никаких EC2, Cloud Run, cold starts. Recurring счёт — один Cloudflare Worker для маркетинг-сайта.
Аудио не покидает устройство (с поправкой на STT-провайдера, которого пользователь сам выбрал и оплачивает своим ключом).
Скейлинг бесплатный. Новый пользователь = новый ноутбук = новый сервер.

Чем плачу:

Онбординг сложнее. «Скачать приложение» — больше трения, чем «поставить расширение и залогиниться».
Не могу автоматически выкатить серверный фикс — нужен electron-updater roundtrip (R2 + electron-updater всё это умеют, но это лишняя движущаяся часть).
Лицензирование живёт на десктопной стороне (LemonSqueezy + крошечный Cloudflare Worker для проверки entitlement).

Для indie SaaS этот трейдоф — no-brainer. Теперь технически интересная часть.

Pipeline

Mic / Tab audio
   │
   ▼
Deepgram Nova-3 (streaming WebSocket, диаризация)
   │
   ▼
TranscriptBuffer (граница предложения + смена спикера + safety timeout 4с)
   │
   ▼
Groq Llama 3.3 70B (streaming, sentence-chunked перевод)
   │
   ▼
Edge TTS (бесплатно, Microsoft Neural voices)
   │
   ▼
Инжекция аудио обратно в Meet

В одном звонке параллельно работают два таких pipeline'а:

Incoming (peerLang → userLang): tab audio → переведённый голос играется в ваших колонках, плюс субтитры.
Outgoing (userLang → peerLang): ваш микрофон → переведённый голос, который произносится в Meet как будто это вы говорите, плюс субтитры для собеседника.

Оба pipeline'а делят один WebSocket. Направление мультиплексируется через prefix-байт (0x00 incoming, 0x01 outgoing). Дёшево, без схем, работает.

End-to-end latency в установившемся режиме — около 1.5–2 секунд. Большая часть — Deepgram, который ждёт, чтобы уверенно пометить чанк is_final.

Дальше — две вещи, на которые ушло больше всего времени.

Хак №1: перехват getUserMedia для инжекции TTS в Meet

Это самая интересная часть.

Когда Meet запрашивает микрофон, он вызывает navigator.mediaDevices.getUserMedia({ audio: true }). Получает MediaStream, и именно этот стрим уходит другим участникам.

Я просто... отдаю ему другой стрим.

// content script, world: "MAIN", runAt: "document_start"
const origGetUserMedia = navigator.mediaDevices.getUserMedia
  .bind(navigator.mediaDevices);

navigator.mediaDevices.getUserMedia = async (constraints) => {
  if (!constraints?.audio) return origGetUserMedia(constraints);

  // Получаем настоящий микрофон, но Meet его напрямую не даём
  const realStream = await origGetUserMedia(constraints);

  // Строим управляемый стрим, на который Meet будет держать ссылку
  const controlStream = new MediaStream();
  for (const t of realStream.getAudioTracks()) controlStream.addTrack(t);
  for (const t of realStream.getVideoTracks()) controlStream.addTrack(t);

  // На следующем user gesture подменим аудио-треки на наш миксованный стрим
  document.addEventListener("click", trySetupGraph, true);
  return controlStream;
};

Сам микс собирается на Web Audio:

audioCtx     = new AudioContext({ sampleRate: 48000 });
destination  = audioCtx.createMediaStreamDestination();
micSource    = audioCtx.createMediaStreamSource(realStream);
micGainNode  = audioCtx.createGain();   // микрофон, с ducking
ttsGainNode  = audioCtx.createGain();   // injected TTS, с boost

micSource.connect(micGainNode).connect(destination);
ttsGainNode.connect(destination);

// Подменяем треки на стриме, на который Meet уже держит ссылку
for (const t of controlStream.getAudioTracks()) controlStream.removeTrack(t);
for (const t of destination.stream.getAudioTracks()) controlStream.addTrack(t);

Когда сервер присылает переведённый TTS:

Декодируем чанки в AudioBuffer.
Опускаем micGainNode до 20% — чтобы вы не говорили поверх собственного перевода.
Играем буфер через ttsGainNode → destination.
На source.onended восстанавливаем gain микрофона.

С точки зрения других участников — они слышат, как вы говорите на их языке. Их клиент Meet не подозревает, что в стриме синтезированный голос — это просто байты в том же MediaStream, который Meet и запросил.

Несколько граблей, на которые я наступил:

AudioContext'у нужен user gesture, чтобы стартовать в running. Поэтому getUserMedia сначала возвращает настоящий стрим, а подмена происходит на следующем click/keydown. Без этого Chrome создаёт контекст в state suspended — silent failure: ничего не падает, но аудио не идёт.
Override-скрипт работает в MAIN world, а значит никаких chrome.* API. Вся коммуникация с расширением — через window.postMessage с targetOrigin: "https://meet.google.com" (никогда "*" — defense-in-depth).
Последовательная очередь TTS — обязательна. Два сегмента, пришедшие подряд и декодированные параллельно, перекроются и зазвучат как два пьяных синтезатора. Достаточно одного флага isPlaying + playNext() в source.onended.
Монотонный счётчик activePlaybackId, инкрементящийся на каждый новый playback. Stale onended от предыдущего сегмента проверяет его и выходит. Без этого быстро пришедший новый сегмент получал восстановленный gain микрофона от старого callback'а — и стартовал на полной громкости.

Хак №2: streaming-перевод без рваного TTS

Deepgram отдаёт два типа финализированных транскриптов: is_final (этот чанк зафиксирован) и speech_final (спикер только что взял паузу). Если переводить каждый is_final — получится мусор: фрагменты по три слова, без контекста, ужасное cache-поведение. Если ждать speech_final — переводы чистые, но пользователь ждёт 2+ секунды до первого звука.

Компромисс — TranscriptBuffer, который флашится по тому, что наступит первым:

push(text, speaker, endTime) {
  // Сменился спикер — сначала флашим предыдущего
  if (speaker !== this.speaker && this.segments.length) this.flush();

  this.segments.push(text);
  const accumulated = this.segments.join(" ");

  if (SENTENCE_BOUNDARY_RE.test(accumulated) && accumulated.length > 20) {
    this.flush();                                        // предложение готово
  } else if (wordCount(accumulated) >= 30) {
    this.flush();                                        // длинный монолог
  } else if (!this.timer) {
    this.timer = setTimeout(() => this.flush(), 4000);   // safety на тишину
  }
}

На стороне перевода: вместо того, чтобы ждать, пока LLM закончит фразу, ответ Groq стримится и пере-чанкуется по предложениям (regex [.!?] после 20+ символов). Каждое предложение уходит в TTS сразу, не в конце стрима. Это пайплайнит TTS-синтез поверх LLM-генерации — первое слышимое слово приходит заметно быстрее, чем при наивном «перевели → синтезировали».

Субтитры обновляются на промежуточных транскриптах (пользователь видит их живьём), TTS играет только на стабильных предложениях. Получается лучшее из двух.

Стек

Deepgram Nova-3 — единственный streaming STT, который у меня нормально диаризовал спикеров в шумных созвонах.
Groq + Llama 3.3 70B — самая быстрая LLM, которую могу позволить в BYOK-продукте. Дешевле GPT-4o-mini за токен и в несколько раз выше throughput. OpenAI оставлен как fallback.
Edge TTS (msedge-tts, MIT) — Microsoft Neural voices, бесплатно, звучат хорошо. OpenAI tts-1 — опциональный upgrade.
WXT — лучший фреймворк для WebExtension, что я использовал. Manifest V3, Vite, TypeScript, content-script worlds, всё работает из коробки.
Electron 41 с ESM tray-приложением — на удивление чисто. utilityProcess крутит WS-сервер в child-процессе, он может крашнуться без последствий для tray.
Astro 6 для маркетинг-сайта — статика, быстро, file-based i18n.

Что отверг:

OpenAI Whisper API — стандартный /v1/audio/transcriptions принимает готовый файл, не стрим. (Новый Realtime API с gpt-4o-transcribe существует, но это уже другой зверь, и появился он слишком поздно для этого дизайна.)
ElevenLabs — красивые голоса, но цена за минуту делает BYOK неподъёмным для ежедневных пользователей.
Традиционный VPS-бэкенд — собственно, против него и весь дизайн.

Три вещи, которые я бы сказал себе в прошлом

BYOK + локальный сервер — это рабочий паттерн. Cost-of-revenue схлопывается до $0. Privacy превращается из маркетингового тезиса в свойство архитектуры. Цена — трение в онбординге, и большинство pro-пользователей охотно меняют его на контроль.
Manifest V3 сложнее, чем признаёт документация. В service worker нельзя держать состояние. Для всего stateful (аудио, persistent WebSocket) нужен offscreen document. chrome.storage в нём недоступен — приходится message-pass'ить с retry. Закладывайте время.
Electron не настолько плох, как пишут в Twitter. Tray-only app занимает ~200 МБ на диске и ~80 МБ RAM в idle. electron-builder подписывает под Mac/Windows. GitHub Actions собирает macOS DMG на macos-latest бесплатно.

Если хочется попробовать: скачайте MeetVoice для Windows или macOS на meetvoice.app и поставьте расширение из Chrome Web Store. Понадобится ключ Deepgram (бесплатного тира хватит на тест), остальное — опционально.

С удовольствием отвечу на вопросы в комментариях — особенно про audio graph и MV3 offscreen-doc dance, на них ушло больше всего боли.