christianandClaude Fable 5.1
81da657094
Build 127. Reported from a live test: part of the translation came out in a
different voice on an Android phone, and iPhones were skipping and repeating.
Three investigations against the campus Mac's own log and transcript, one
test harness driving the voice process directly, and the answer is not what
it sounded like.
WHAT THE MACHINE DID. One voice process ran all afternoon. Every language
kept a single resident engine from its first sentence (14:54:26) to STOP
(15:23:18); 2,800 clips, 560 per language, every one filed under its own
language and spoken by its own bundle. No synthesis-side voice change was
possible with that configuration. What the log shows at the time of the
complaint instead:
- Someone on the English stream heard the ROOM MICROPHONE for 21 s
(15:09:10-32). English was the first button on every phone's list, forced
there by the page whatever the operator had chosen (fixed in build 125).
- A listener tapped Chinese at 15:11:17. The 121 MB zh model was fetched
and unpacked THREE TIMES AT ONCE on the voice process's only thread.
Every stream stalled for about a minute, 26 sentences were dropped across
all five languages, and the catch-up rushed the Spanish voices to their
+16% cap. Same voice, sounding wrong.
WHAT WAS WRONG, AND IS NOW FIXED.
The live path filed every engine as an "audition". speak() resolved the
language's default voice, which always has a bundle, and passed it as
`explicit`, so the key was 'audition:'+bundle for every ordinary sentence
while the preload warmed copies under the language name that no sentence
ever read. Five languages asked for nine engines against a cap of six; every
service's first sentence built its real engines on the spot (1.3-2 s); the
operator's voice save flushed nothing that mattered. Engines are now keyed
by bundle and shared by every language, variant and audition that uses one,
auditions take at most two slots of their own and can never evict a live
engine, and the cap is 8, sized to the largest campus from measurement
(~165 MB per engine once it has spoken, 1.3 GB for eight).
Voice installs ran on the thread that answers every sentence, and were not
de-duplicated. They now run in a worker thread (voice-install.js), one per
bundle however many ask, staged and renamed into place whole so a half-
written bundle can never pass isInstalled().
Listener rows are { code, count } and engine.js read { lang, n } in five
places, so the set of "languages someone is on" was always empty — and a late
sentence keeps speech only for those. Under load the app dropped EVERY
language's speech instead of only the unchosen ones. Late became silent.
HLS segment numbers restarted at 1 for every new stream object, under a
'max-age=60, immutable' header. A phone back from the lock screen could be
answered from its cache with the previous stream's audio under the new
number: an earlier sentence, replayed. Numbers are seeded from the clock.
In clips mode a clip still downloading when the listener switched language
landed and played in the voice they had left; the frame now carries its
language and voice and the page checks both when the bytes land. In stream
mode the old playlist stayed loaded through a switch and three things could
restart it; it is stopped, not paused. A listener's alternate voice no longer
loses a round trip to the default on the original-text toggle.
One genuine wrong-voice path, dormant today because natural voices are off on
this campus: a variant waiting on another variant's premium synthesis
inherited that variant's Piper FALLBACK, in that variant's bundle — spa_ES
received the byte-identical Mexican clip and its own voice never loaded. A
follower now shares a fallback only when it is its own voice.
An audition (the Voices card's play button) played on the system default
output, which on the campus Mac is the Dante card feeding the hardware
channels. It now plays on another output, or refuses and says why.
VERIFIED: a harness drives the voice process through the baseline, a batch
of four auditions during live sentences, a voices save mid-stream, and nine
live languages against the cache — every clip spoken by its own bundle, and
auditions of a live voice now cost 78-311 ms with nothing rebuilt.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Church Translate
Live sermon translation into 100+ languages. One Mac app per campus. No servers, no deployment, no subscription.
Congregants point a phone camera at a QR code, tap their language once, and read along — or let their phone read it aloud in their ear. No app, no account.
Built because Kaleo is $24–149/month and OneAccord starts at $150/month for five hours, and both are wrappers around cloud speech and translation APIs that an M-series Mac runs locally for nothing.
How it works
Everything is inside the one app. Install it on the Mac at a campus, point it at the pastor's microphone, and it serves the congregation page itself.
┌──────────────── one Mac, one campus ─────────────────┐
│ │
│ Dante ─┐ │
│ Waves ─┼─► audio in ──► voice detection │
│ M32 ───┘ │ │
│ ▼ │
│ Whisper (Mac GPU) │
│ │ │
│ NLLB-200 (separate process) │
│ │ │
│ built-in web server ──────────────┼──► phones on
│ │ the WiFi
└───────────────────────────────────────────────────────┘
No audio ever leaves the Mac, and nothing leaves the building unless you choose to publish it. Only finished sentences cross the network, so a full auditorium costs almost nothing to serve.
Two details that are not preference but necessity: translation runs in its own plain-Node child process, because Chromium's allocator refuses the model's gigabyte-sized weight blocks and kills the process; and speech recognition runs on the GPU while translation runs on the CPU, because neither fits in the other's runtime.
What it costs
| Speech recognition | Whisper large-v3-turbo, on the Mac's GPU — $0 |
| Translation, 100+ languages | NLLB-200, on the Mac's CPU — $0 |
| Spoken audio | The listener's own phone — $0, at any scale |
| Serving the page | The app itself — $0 |
| Dante input | Dante Virtual Soundcard, ~$50 once per campus — or free via Waves or console USB |
Performance
Measured on an M2 Max, from the end of a spoken sentence to captions on a phone. Partial text appears well before that, so it feels quicker than the numbers.
| Live preview | updates every 500–800 ms while the sentence is still being spoken |
| Finished sentence | ~1.6 s behind the speaker |
| Speech recognition | 4.9× real time (accurate model) |
| Translation | ~390 ms per language, flat over 240 consecutive runs |
| Memory | plateaus at 10–11 GB; no drift across a long service |
Two speech models run at once: a fast one drives the live preview, an accurate one produces the line the congregation keeps. They run on separate tracks, so the preview costs the finished caption almost nothing.
Getting started
- docs/SETUP.md — installing at a campus
- docs/AUDIO.md — Dante, Waves SoundGrid, console USB
- docs/COMPANION.md — the Stream Deck button
- docs/SUNDAY.md — print this and tape it to the desk
- docs/PUBLIC-ACCESS.md — optional, for people off-site
cd app && npm install && npm start # run from source
cd app && npm run dist # build the .app
Things worth knowing
- Only languages people are actually listening to get translated. Nobody on Icelandic means no CPU spent on Icelandic. Pin a language on the operator page to have it ready before the first person arrives.
- Corrections beat retraining. Operator page → Corrections →
have a cook => Habakkuk. Whole-word, case-insensitive, instant. - A late arrival sees the last 40 lines, so walking in halfway still makes sense.
- Transcripts are written per service, original and every translation, under
~/Library/Application Support/Church Translate/data/transcripts/. - Each campus is independent. Nothing is shared, nothing syncs, and one campus being down has no effect on another.