Building a Translation Extension for Chrome: MV3 Lessons
A developer shares insights on building a real-time translation extension for Meet, Zoom, and Teams, addressing MV3 audio hurdles and cutting costs 17x.
Stock photo for illustration only, not from the actual event
- Developed a Chrome extension for real-time meeting captions on Meet, Zoom, and Teams without bots.
- Resolved MV3 limitations by leveraging offscreen documents and AudioWorklet for tab audio streams.
- Switched to a single-stream provider, dropping operating costs from $2.55 to $0.154 per hour.
- Tested latency and accuracy using a Linux box simulating four browser profiles simultaneously.
A software developer has detailed their journey of building a standalone Chrome extension that displays translated captions over browser-based calls in Google Meet, Zoom, or Microsoft Teams. The core architecture relies on capturing audio directly from the browser tab rather than routing a virtual bot into the meeting, with figures reported as of September 17, 2026.
The initial hurdle lay within Manifest V3 (MV3), where extension background scripts operate as service workers devoid of Web Audio or getUserMedia APIs. To bypass this, the service worker retrieves a stream id and spawns an offscreen document—an invisible webpage hosting these APIs—utilizing AudioContext and an AudioWorklet to downmix channels to mono and emit Int16 PCM blocks of 4,096 samples.
Stock photo for illustration only, not from the actual event
Another major obstacle was the "Cannot capture a tab with an active stream" error, which occurs when a previous tab capture fails to release properly. Standard page reloads or chrome.runtime.reload() calls do not clear this state because the stream persists inside the offscreen document. Even closing the document requires caution, as Chrome releases streams asynchronously, necessitating state polling instead of arbitrary timeouts.
The migration to Manifest V3 (MV3) introduced strict security boundaries that separate background processes from direct DOM and audio pipelines. Developers must adopt patterns like Offscreen Documents and AudioWorklets to bridge legacy audio APIs into modern extension architectures, highlighting the evolving complexity of browser-based audio processing.
The initial prototype relied on Deepgram for speech recognition and DeepL for translation. To prevent translated text from appearing in a sudden jump at sentence ends, interim recognition results were translated continuously. However, because DeepL bills by source length, unfinished sentences kept growing and were re-submitted in full, driving up hidden costs.
Measurements taken on August 29 using a real Deepgram socket and a test track revealed that 2.53 times more characters were sent to translation compared to translating final phrases only, resulting in an hourly call cost of roughly $2.55. The solution involved migrating to Soniox using the stt-rt-v5 model, which handles both speech recognition and translation within a single unified stream.
"stt-rt-v5, $31.23 for 202.6 hours of audio, which is $0.154 per hour. Against $2.55 with two services, that is 17 times less."
Extension Developer
According to usage summary data from August 30 to September 17, processing 202.6 hours of audio via stt-rt-v5 cost a total of $31.23, averaging out to $0.154 per hour. Compared to the previous setup of $2.55 per hour, this achieved a 17-fold reduction in costs, though the trade-off manifested as slightly higher latency.
To rigorously evaluate performance beyond unit tests, the developer configured a Linux test stand where three Chrome profiles joined a single call reciting a pre-synthesized 118-line interview script, while a fourth profile ran the extension to log caption metrics, speaker tags, and response latencies.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment