Inside my-translator: one 16kHz audio path feeding four translation engines

Four engines hang off one 16kHz audio capture path

Every engine in this app listens to the same thing: a 16kHz PCM stream taken from system audio or from the microphone, then split four ways. Soniox hands back text. OpenAI Realtime returns translated text and translated speech over a single WebSocket. Qwen LiveTranslate Flash returns text and nothing else. Local MLX returns text with no network involved at all. Whatever arrives lands in one overlay, and for text-only engines the result can then be passed to a synthesiser.

Two display modes sit on top of that stream. One is Single, which shows translation text only and is the default, and the other is Dual, which puts source and translation side by side with each panel scrolling on its own. The panel button lives in the bottom-right corner and shows on hover, so it stays out of the way until you reach for it.

Scrolling is conditional rather than automatic: auto-scroll engages only when you are already at the bottom, which means scrolling up to reread an earlier line does not get dragged back down mid-sentence. The A- and A+ controls, in that same corner, push the font as far as 140px. On a projector, or across a meeting table, a 140px ceiling is the difference between a caption you can follow and a wall of text you cannot.

The privacy claim and the three cloud endpoints behind it

One line of the documentation says audio never reaches anyone's servers because the project itself has none. The same document then names three engines that live on somebody else's endpoint. OpenAI Realtime streams over one WebSocket to `gpt-realtime-translate`. Qwen LiveTranslate Flash streams from DashScope, and its own regional note makes that endpoint explicit: Singapore only, because other regions hit a different endpoint and fail. Soniox is quoted per hour against a key you hold, which only makes sense for a hosted service.

Read that privacy line as a claim about the application's architecture rather than about your audio staying on your machine. The repository layout backs the first half of that reading. package.json declares exactly two runtime dependencies, `@tauri-apps/plugin-process` and `@tauri-apps/plugin-updater`, and no server component appears among the top-level repository entries. What does not follow is the second half: three of the four engines hand audio to a third party, and no relay of the author's own would change that.

Local MLX is the narrow exception. It runs on the device with MLX, Whisper and Gemma, and covers Japanese, English, Chinese and Korean into Vietnamese or English. Choose it and the privacy line becomes literal, at the price set out in the latency figures below.

Downloading a signed build, or running the Tauri scripts

End users build nothing, and the download table maps machine straight to file:

MyTranslator_<ver>_aarch64.dmg
MyTranslator_<ver>_x64.dmg
MyTranslator_<ver>_x64-setup.exe

A Mac answers the question itself: About This Mac shows Chip as either Apple M-series or Intel, and machines from late 2020 on are almost all Apple Silicon. The download page also carries .app.tar.gz, .sig and latest.json, none of which are meant for people, since they feed the built-in updater that checks and installs from the Settings panel. macOS builds are signed and notarised, and the last push landed on 2026-07-11.

Working from source means the npm scripts in package.json, three of which matter:

node scripts/tauri-with-env.mjs dev
tauri dev
npx serve src -p 3111

The first wraps Tauri so environment variables reach the process, the second skips that wrapper, the third serves the frontend alone on port 3111. Static checks run through Rust instead:

cd src-tauri && cargo clippy
cd src-tauri && cargo fmt

That last pair is the clearest signal about the stack. package.json names no Python interpreter, no environment setup and no Python package, yet the repository's primary language is recorded as Python while the shell is a Tauri app with an src-tauri directory. Where that Python lives is not visible in the files listed here. The MLX, Whisper and Gemma combination named for local mode is the only place the documentation points at model code, and it never says what language runs it.

Two-way mode and the two engines that switch it off

Bilingual calls are what the app is shaped around. Set Audio Source to Both, Translation Type to Two-way, name language A and language B, and the app works out who is speaking and sends the result to the other language. That mode also mutes TTS narration, because synthesised speech would travel back into the microphone and be retranslated as if a person had spoken it.

The trouble is that two of the four engines take two-way away from you. Both OpenAI Realtime and Qwen LiveTranslate Flash disable it, and both disable the custom TTS toggle along with it. Select either and you are left with one-way translation plus whatever voice that engine produces on its own. OpenAI streams its own translated speech and keeps that path off by default. Qwen produces no voice at all.

Qwen adds a further restriction with a concrete failure attached. Language auto-detection is switched off there, and the consequence is stated plainly: Live Flash stalls on real microphone input when the source is set to auto. Choose the source language by hand. The regional limit is just as blunt, since a key issued outside Singapore reaches a different endpoint and fails outright.

Latency and cost spread four different ways across engines

In a live conversation, latency is the axis that decides whether you use this at all, and the four engines are five times apart. Soniox and OpenAI Realtime land near 2 seconds. Qwen sits around 4 seconds. Local MLX takes about 10 seconds, long enough that a fast exchange of turns becomes something you wait out.

Cost runs the opposite way. Soniox is quoted at roughly $0.12 per hour, OpenAI Realtime at about $4 per hour with its voice included, Qwen on a free preview tier, and local mode at nothing. The distance between those two figures buys exactly one capability: OpenAI returns translated speech in the same call instead of sending text onward to a separate synthesiser.

Coverage splits along the same seams. Soniox pairs 70-plus source languages with any target. OpenAI Realtime lists 13 targets, en, es, pt, fr, de, it, ru, hi, id, vi, ja, ko and zh. Qwen carries a 60-language picker matching its mobile app. Local MLX accepts only Japanese, English, Chinese and Korean as source and produces Vietnamese or English. Two of those four combinations are unreachable on any other engine, which is the practical reason the Apple Silicon only path still matters.

Three synthesiser providers, and the loop the app refuses to make

Text-only engines can speak their output through Edge TTS, Google Chirp 3 HD or ElevenLabs. Edge is free, needs no setup and offers two Vietnamese voices. Google is free up to a million characters a month with six Vietnamese voices, but wants an API key. ElevenLabs starts around $5 a month. Edge and Google give you rate control, ElevenLabs does not.

Narration is off by default in one-way mode and comes from the TTS button or its keyboard shortcut. Leaving it off during a call is not a preference, because the app refuses to narrate in two-way mode for the reason given earlier.

The Google row carries a wrinkle worth reading twice. The provider table says setup requires a Google Cloud API key, while the environment template describes something different: `GOOGLE_FREE_TTS_KEY`, tied to an android-tts endpoint and embedded at build time through build.rs. The template calls that build key optional, states that a key entered in Settings under TTS takes priority over it, and says that when both the user key and the build key are empty the provider is disabled with no hardcoded fallback. A build made without that variable therefore ships with the Google option unavailable, and the provider table does not say so.

Build-time secrets and the identifier that splits permissions

The environment template opens by telling you to copy it to .env, which is gitignored, and states plainly that secrets are read at build time rather than at run time. Three things live in that file. A commented `APPLE_PASSWORD` for macOS notarisation. The `GOOGLE_FREE_TTS_KEY` just described. And a commented `APP_IDENTIFIER` override.

That last line is the one that matters while developing. Setting it to a distinct value, `com.personal.translator.dev`, gives the development build its own macOS Screen Recording and Microphone permissions, so the installed app keeps the grants it already has while you iterate. Leave it unset and the default identifier from tauri.conf.json applies, which means your dev build and your installed app compete for the same screen recording permission, and each rebuild can re-prompt you.

A second consequence follows from build time reading. Anyone who downloads the signed DMG never runs these scripts, so the optional keys baked into their binary were fixed by whoever built it, not by the person using it. The template's no hardcoded fallback note means the Google provider's availability is decided at packaging, not at first launch. The project ships under the MIT licence, and nothing in the repository adds a separate contributor agreement on top of it.

Editorial conclusion

my-translator is worth an afternoon if you run bilingual calls and can supply your own keys, but it is not a set and forget tool: every engine trades latency against cost against language coverage, and two of the four remove features you may need. Before anything else, confirm your language pair exists on the engine you plan to use, check that your DashScope key comes from the Singapore region, and set GOOGLE_FREE_TTS_KEY at build time if you expect Google narration. If two-way conversation is the requirement, start on Soniox.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. phuc-nt/my-translator on GitHub
4. README
5. Releases