Production Project
A production RU ↔ EN push-to-talk voice translator that grew from a simple speech pipeline into a benchmark-driven engineering laboratory.
Type
Voice translation application
Focus
Speech pipelines, benchmarking & realtime delivery
Status
v1.0.0
01 / The Project
The original idea was deliberately simple: press a button, speak Russian, and hear English speech back. Then do the same in the opposite direction.
Once the basic speech-to-text → translation → text-to-speech pipeline worked, the difficult question changed. It was no longer whether voice translation could be connected, but which technology was accurate and fast enough for practical near real-time conversation.
That question turned the project from feature development into an R&D exercise involving controlled recordings, multiple speech providers, repeatable benchmarks, browser-side timing and finally a production demo.
Turning Point
One of the most important tests involved my cat, Persik. Google recognized the Russian phrase “Кот Персик рыжий хулиган” as “Код Персик рыжий хулиган”. The mistake was plausible: in Russian, the final consonants in “кот” and “код” can sound almost identical without enough context.
Adding context fixed the recognition. That tiny experiment changed the direction of the project: instead of asking whether speech recognition worked, I started asking which speech technology was actually good enough for near real-time Russian-English communication.
First test
Кот Персик рыжий хулиган.
Код Персик рыжий хулиган.
With more context
У меня есть кот Персик, он рыжий хулиган.
Recognized correctly
Later in the pipeline
Персик
Peach
Persik exposed two different failure modes: speech recognition could misunderstand a word, and even a correct transcript could still be translated incorrectly. That is why the project eventually benchmarked the complete pipeline instead of trusting one successful API call.
02 / Production Pipeline
The production workflow is divided into measurable stages so recognition, translation, synthesis and delivery can be evaluated independently.
01 / Input
The browser records a short WebM audio sample. Explicit Start and Stop controls keep the conversation model predictable while the project focuses on reliable translation rather than pretending to provide full-duplex simultaneous interpretation.
02 / Speech-to-text
Language-specific Google Chirp 3 streaming profiles were selected from benchmark results instead of forcing Russian and English through one universal configuration.
03 / Translation
Recognized text is translated between Russian and English. Translation was benchmarked separately because a correct transcript can still produce an incorrect meaning.
04 / Voice output
Translated text is converted into audio and returned to the browser, where playback timing becomes part of the user-facing latency measurement.
Selected production profiles
Russian input → Chirp 3 Streaming STANDARD → DeepL → OpenAI TTS. English input → Chirp 3 Streaming SHORT → DeepL → OpenAI TTS.
03 / Engineering Lab
The benchmark began as command-line tooling and evolved into a browser-based Live Pipeline Lab where the same recording can be replayed through different complete profiles.
Controlled input
The same captured WebM audio can be reused across profiles, avoiding the false comparison created when a person simply tries to repeat the same sentence several times.
Profiles
Batch Chirp 3, Streaming STANDARD, Streaming SHORT and Deepgram Flux can be compared using the same surrounding translation and TTS stages.
Measurements
The Lab records STT, translation, TTS, audio-ready and browser playback timing instead of reducing the entire experience to one provider request.
Persistence
Transcripts, translations, timing data, quality labels and historical runs are stored for later review and profile comparison.
04 / Benchmarking
The benchmark used controlled recordings with logistics-oriented phrases and evaluated critical-element preservation. Losing an article is not equivalent to changing 15 into 50, a truck identifier, destination, temperature or operational instruction.
Best measured RU quality
93.33%
RU STANDARD STOP → audio
1701 ms
EN SHORT STOP → audio
1677 ms
| Profile | RU quality | EN quality | RU STOP → audio | EN STOP → audio |
|---|---|---|---|---|
| Batch Chirp 3 | 93.33% | 90.63% | 2104 ms | 1982 ms |
| Streaming STANDARD | 93.33% | 90.63% | 1701 ms | 1850 ms |
| Streaming SHORT | 90.00% | 90.63% | 1315 ms | 1677 ms |
| Deepgram Flux | 86.67% | 78.13% | 1236 ms | 1279 ms |
Engineering decision
Russian keeps Streaming STANDARD because it preserves the strongest measured 93.33% quality while improving latency over batch recognition. English uses Streaming SHORT because it retained the same measured 90.63% quality as STANDARD while reducing both recognition and complete STOP-to-audio latency.
05 / Public Demo
The public interface exposes the real translation workflow while deliberately removing most experimental choices. The server, not the browser, owns trusted pipeline configuration.
Session
Before opening the WebSocket pipeline, the browser requests a short-lived demo session. The backend validates the source language, selects the configured profile, reserves quota and issues a one-time token.
Limits
The server limits recording duration and audio size and applies visitor, IP and global quotas so the demo does not become an unlimited speech API proxy.
Trust boundary
Public clients cannot choose arbitrary providers, experimental profiles or trusted source configuration. Those decisions remain server-side.
Operations
The public demo can be disabled independently, while the experimental Live Lab remains separately protected from public production access.
06 / Production & Delivery
After the pipeline and Lab worked locally, the project was deployed as separate production services instead of remaining an impressive collection of terminal windows.
Hosting
The production system runs on Railway with separate services for the Laravel web application, WebSocket pipeline server and MySQL.
Realtime
The WebSocket service handles live audio processing independently from normal web requests and public demo session creation.
Runtime
The production PHP 8.4 runtime includes the extensions required by the speech stack, including gRPC, protobuf, intl, pcntl and MySQL support.
Credentials
Provider secrets stay in environment configuration. Google service-account credentials can be supplied as JSON in production instead of relying on a locally mounted file.
Domain
The public RU ↔ EN demo runs through a dedicated HTTPS production subdomain.
Validation
Tests, PHPStan, Laravel Pint and the frontend production build are used to validate the project before release.
Production setup
Laravel, Railway, MySQL, dedicated WebSocket service, Google Speech-to-Text, DeepL, OpenAI TTS, HTTPS and a custom domain.
07 / Current Limitations
The project keeps its current boundaries explicit instead of presenting a push-to-talk production demo as finished simultaneous interpretation.
Communication is push-to-talk, not full-duplex simultaneous translation.
The current public demo focuses on RU ↔ EN; Lithuanian remains a future language extension.
Quality and latency still depend on network conditions and external cloud providers.
Sending translated speech directly between two separate computers or into conferencing software remains future work beyond the current portfolio demo.
08 / Technology Stack
The project combines a Laravel application with browser audio capture, realtime communication, persisted benchmark data and specialized speech and language providers.
Application
PHP 8.4
Laravel 13
Blade
Vite
Speech & language
Google Speech-to-Text
DeepL
OpenAI TTS
WebM audio
Data & realtime
MySQL
WebSockets
Persisted Lab runs
Browser timing metrics
Engineering
Docker
Laravel Sail
PHPStan
Laravel Pint
CI
09 / Result
Voice Translator demonstrates more than connecting several AI APIs. The project uses controlled recordings, critical-element preservation and end-to-end timing to decide how different pipeline choices affect both accuracy and the delay a user actually experiences.
It also shows the path from an accidental speech-recognition problem involving a cat to a repeatable R&D workflow, a browser-based engineering Lab and finally a controlled production application with explicit trust boundaries and public safeguards.
Streaming speech processing
Controlled benchmark methodology
Critical-element preservation
End-to-end latency measurement
Provider and pipeline comparison
Production deployment and safeguards