# Text to speech

Text-to-speech takes wording you have already decided and speaks it. That is its whole advantage: the sentence is fixed before any audio exists, so it can be prepared early and played exactly. Connect synthesises the greeting with Google Text-to-Speech and plays it while the line is still connecting; the rest of a realtime call is spoken by the speech-to-speech model, not by a synthesiser.

- **Status:** Reference
- **Audience:** both
- **Channels:** phone
- **In the app:** #/calls, #/phone-advanced
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/tts/

## Why a synthesiser survives on a model-spoken call

It looks redundant to keep a synthesiser on a path whose model already speaks. It is not, because the two are good at opposite things. A generated reply is decided as it is spoken, which is what makes it responsive and what makes it unrepeatable. A synthesised line is decided first, which makes it exact and makes it available *before* the model has produced anything at all.

That second property is the one that matters at the start of a call. The greeting is prepared ahead of the answer and begins during the ring, which removes the pause a caller would otherwise hear while a model warms up. The prewarm window is measured in milliseconds ahead of the answer rather than after it, and it is the difference between a line that sounds answered and one that sounds broken.

| Audio | Produced by | Decided when |
|---|---|---|
| The greeting | Google Text-to-Speech, played during the ring | Before the call, from the workspace's configured wording |
| Everything after it, on the realtime path | The speech-to-speech model | As it is spoken |
| Anything on the turn-based carrier path | The carrier engine's own playback | Per turn |

## What a style instruction changes, and what it does not

A modern synthesiser accepts a natural-language direction — speak warmly, unhurried, with a short pause after the company name — rather than only a voice identifier and a rate. That moves a great deal: pace, warmth, where the emphasis falls, how a greeting lands in a particular region.

It does not move meaning. The synthesiser has no idea what the sentence is for, so it cannot fix a sentence that is wrong, cannot shorten one that is too long, and cannot notice that the caller has already answered the question it is about to ask. A style instruction is direction for an actor who cannot see the script's context.

- **Pronunciation of names is not reliable.** Company and personal names, especially across scripts, are the first thing to check by ear rather than by reading the text back.
- **Length is your problem.** A synthesiser will happily read forty seconds of greeting. Callers will not listen to it.
- **Style is not identity.** A direction to sound like a particular person is not a voice profile, and Connect's human voice profiles are a separate mechanism with their own character budget of about 2,500 characters.

## Does Connect use text to speech?

**Used, in one specific place.** `voice_tts` is production capability and carries the workspace's own voice: it synthesises the greeting, and it is what the preview on the voice screens plays when you are auditioning a greeting before a real caller hears it. Both audiences reach it through the same module — the public configuration and the preview live in `voice_tts`, and the Owner and customer routers each add only a route.

It is **not** used to speak the body of a realtime conversation. If you are reading this to work out where a particular sentence came from: fixed wording at the start of the call came from the synthesiser, and anything that responded to something the caller said came from the model.

## Failure modes worth knowing

**The greeting plays late** — The prewarm did not happen, so synthesis started at answer time instead of during the ring. The caller hears the gap as hesitation.
**The greeting is cut in half** — Something treated the caller's first sound as an interruption. Connect ignores apparent barge-in for the first two seconds for exactly this reason.
**The preview sounds different from the call** — A preview plays through your browser's audio path; a call plays through a carrier codec. Judge wording and pace on the preview, judge intelligibility on a real call.
**A name is mispronounced** — There is no spelling correction downstream. Change the written form until it reads correctly aloud — that is the only control the synthesiser gives you.

## Questions

### Can Connect clone a specific person's voice?

That is not what the voice profile mechanism does. A profile is a written description of how somebody speaks — pace, register, habits — kept under about 2,500 characters because a longer block measurably delays the first token. It shapes delivery; it does not reproduce a particular individual.

### Why not synthesise the whole call and keep total control of the wording?

Because you would be back to recognise, reason, synthesise, and paying three latencies for one answer. The trade is deliberate: fixed wording where it is worth a delay you can hide, a generated voice everywhere the reply has to arrive quickly.

### Does the greeting have to finish before the caller can speak?

No. The caller can interrupt it, subject to the two-second guard that stops an acknowledging noise from being read as an interruption. A caller who genuinely talks over the greeting is answered.

## Related

- [Speech-to-speech models](https://connectbyjbrh.com/docs/technology/speech-to-speech/)
- [Voice profiles](https://connectbyjbrh.com/docs/technology/voice-profile/)
- [Multilingual voice](https://connectbyjbrh.com/docs/technology/multilingual-voice/)
- [Barge-in](https://connectbyjbrh.com/docs/technology/barge-in/)
- [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/)
- [Barge-in without cutting the greeting in half](https://connectbyjbrh.com/research/barge-in-without-cutting-the-greeting/)

## What this page is based on

- Connect capability registry (docs-source/facts.py) — `own_tts_voice`, `human_voice_profiles`, MEASURED
- Connect source pack (docs-source/sources/GENERAL.md §1) — one body, two doors
- Project instructions (CLAUDE.md) — `voice_tts.public_config/preview` shared by both routers