Speech synthesis: where Google Cloud Text-to-Speech breaks down
Speech synthesis sounds smooth until the first real load.
On a test string everything is clean, but in production traffic speech synthesis failures surface: abbreviations are read letter by letter, Latin script inside a Russian phrase gets the wrong stress, SKUs and numbers are voiced as dates. The user hears not their industry but a voice that doesn't know it.
The second group of failures is timing. A long response is sent for voiceover in full, hits a timeout, and the interface is left in silence: no error, no sound.
The delay before voice output grows with text length, and while the first syllables haven't arrived, the screen has already shown the answer — hence the desync of text and voice, when highlighting runs ahead of the sound or lags behind it.
The cost of these failures is higher than it seems in a demo.
Voiceover stops being a delivery channel and becomes a source of support requests: some sessions break off midway, operators manually restart synthesis, and voice scenarios quietly drop out of the product — they simply stop being enabled.
The cause is usually not in Google Cloud Text-to-Speech itself, but in how it is connected: without a pronunciation dictionary, without delivering audio as it becomes ready, and without reusing already synthesized phrases.
Below we break down how this is addressed — from a terminology dictionary and pause configuration to splitting long responses into short utterances.
What changes after configuring speech synthesis
After moving synthesis to Google Cloud Text-to-Speech, not only the sound changes but also the way voiceover is handled. The result is checked against a list: each item is measured before and after, not evaluated by ear.
- Consistent pronunciation across the entire volume. Stress in terms, abbreviations, numbers, and dates is read the same across all channels — from the voice menu to the training course. Manual proofreading of samples goes away: errors are caught at the markup level, not after publication.
- Unified brand sound. The voice and set of pronunciation rules are fixed in the configuration, so the ad, auto-attendant, and podcast sound like one product. New text is voiced with the same voice without studio re-recording.
- Text edits for voice are reduced. SSML markup decouples text and intonation: pauses, stress, and tempo are set by tags, not by rewriting a phrase "so it sounds right." The editor stops adapting wording to the synthesizer.
- Voiceover load is distributed. Batch processing and caching of repeated fragments smooth out peaks: requests don't pile up in the queue, and there are no failures during peak demand hours.
- A class of errors is eliminated. Broken names, incorrect abbreviations, and swallowed endings are covered by the dictionary and replacement rules — configured once for the entire project.
We verify the result by three numbers: the share of segments accepted without manual editing, the share of channels with a unified voice, and the number of voiceover failures during peak hours.
Synthesis modes: streaming, batch, with caching
Google Cloud Text-to-Speech delivers audio in two ways — streaming and batch — and the third mode, audio caching, is built on top of either.
The difference shows not in voice quality but in how the application receives the result: in chunks as synthesis progresses or as one ready file.
Streaming synthesis returns the first fragment while the service is still reading the rest of the phrase — this is what a human dialogue needs.
Batch voiceover delivers a whole file: stability is higher and cutting by timecodes is easier, but the listener waits in silence until the entire text is synthesized. Cache and file pre-generation remove this delay where wording repeats.
| Speech service mode | When it fits | Limitations |
|---|---|---|
| Streaming synthesis | Voice assistant, voiceover of a reply in chat, real-time hints | The client must be able to assemble chunks; a connection break loses part of the phrase |
| Batch voiceover | Long texts, video, podcasts, audio versions of reports | Delay to first sound equals synthesis time of the entire text |
| Audio caching and pre-generation | Fixed phrases: greetings, menu, order statuses, errors | Doesn't work for dynamic text; invalidation is needed when voice or text changes |
How the mode is chosen
In practice, modes are combined: reference phrases are served from pre-generation, long texts are synthesized in batch in the background, and live dialogue goes through streaming.
The cache key is built from a hash of text, voice, speed, and format — if any parameter changes, the entry stops being reused, so invalidation rules are built in from the start, not after the first mismatch between voiceover and on-screen text.
Implementation stages: from text audit to handover of rules
Work goes from text to regulations: first we analyze what exactly will be voiced, then we describe calls to Google Cloud Text-to-Speech and the markup, and only after that do we lock in the rules.
This order removes a typical failure when voiceover sounds smooth but breaks on real phrases with SKUs, dates, and abbreviations.
- Audit of voiceover texts. We collect a corpus: interface utterances, hints, error messages, numerals, Latin script, enumerations. We mark places that need non-literal reading — dates, units of measurement, names, titles.
- Service call scheme. We decide who calls synthesis — the server, the application, or pre-generation in storage; where access keys are stored, what response timeout and retries are set, and what is saved and reused.
- Configuring voices and pronunciation markup. We select the model and voice for the product's character, set tempo, pitch, and pauses. For terms and brands, we create custom lexicons and markup tags: how to read a number, what to replace an abbreviation with, where to place stress.
- Acceptance check of phrases. We run a control set on real scenarios, listen to each phrase, and count the share of correct pronunciations before and after edits. A discrepancy is a reason to revert to the previous voice or markup variant.
- Handover of regulations. We provide instructions to the content team: how to add new phrases, which tags are allowed, where lexicons are stored, how voiceover texts are versioned, and how to roll back an unsuccessful change.
Text-to-Speech artifacts: glossaries, rules, call schemes
Speech synthesis is not a single call but a configuration layer that lives longer than the code. If lexicons and markup rules are kept in someone's head, every text edit turns into re-listening to all voiceover and manual reconciliation.
That's why, along with the integration, we hand over configuration and documentation suitable for versioning and review.
Below is the set that remains in your repository after integrating Google Cloud Text-to-Speech and covers routine edits without a developer.
- Pronunciation glossary — a lexicon for abbreviations, place names, product names, and units of measurement: a separate file with phonetic variants, not strings inside code.
- Pause and stress rules — SSML markup: where to place a pause on punctuation, how to read numbers, dates, and abbreviations, and permissible tempo and tone for interface hints.
- Call scheme — the sequence "client → synthesis service → cache → storage" with response timeout, retries, request length limit, and splitting long texts into parts.
- Voiceover fault tolerance policy — behavior when the service is unavailable: serving previously generated audio, switching to a backup voice, background regeneration with notification.
- Audio cache and versioning — key from text, voice, and synthesis parameters; invalidation when the lexicon is edited, so old pronunciation doesn't remain in the output.
- Edit regulations — who adds a word to the glossary, on which set of reference phrases the change is checked, and at what point it goes to the production environment.
- Speech synthesis documentation — voice and language map, line length limits, text requirements from the content team, procedure for connecting a new language or character.
Case study: a voice assistant with hundreds of thousands of voiceovers per day
A voice assistant that handles incoming requests and voices several hundred thousand short utterances per day initially ran on studio recordings by a voice actor. Phrases were recorded in batches, and every wording edit turned into a separate recording and editing session. The pipeline relied on studio throughput, not on service load.
The main cost turned out to be not the recording itself but the desync.
Utterances recorded on different days diverged in tempo and intonation, the pronunciation of names, abbreviations, and numerals had to be verified manually, and a new wording reached the production pipeline only after editing. At peaks, the assistant fell back to spare recordings — the scenario lost coherence.
What was changed and what the result was
We moved voiceover to synthesis with Google Cloud Text-to-Speech, leaving the voice actor only for intro and brand utterances.
Pronunciation was locked in with dictionaries: names, abbreviations, and numerals are read the same across all scenarios, and pauses and stress are marked up directly in the utterance texts. Frequent responses are served from cache, and for peak hours scenarios are synthesized in advance.
The time from text edit to voiceover in the production pipeline dropped from two days to minutes, and the share of utterances sent for manual re-recording fell from several percent to fractions of a percent.
Peak load was handled without expanding the studio pipeline, and voiceover stability no longer depended on which shift recorded the fragment.
How streaming synthesis differs from batch synthesis
Streaming and batch synthesis in Google Cloud Text-to-Speech run on the same voices — the difference is in how audio is delivered. In streaming mode, audio arrives in parts as it becomes ready; in batch mode, you get a whole file after text processing. This is where the scenarios diverge, with each mode winning in its own.
Streaming synthesis gives an instant voice response: playback starts while generation is still ongoing, and the pause before the first phrase is reduced to fractions of a second.
This is the mode for live dialogue — a voice assistant, reading a response in real time, simultaneous interpretation.
The limitations are mirror-image: the utterance is delivered in short fragments, pause and intonation markup is trimmed, and there is no ready file at the output — on repeat, the service is called again.
The batch option works the opposite way: the text is sent in full, and the output is a prepared audio file.
All pronunciation markup is available: stress, pauses, abbreviations, and numbers — and the result can be stored, versioned, and served from your own storage without calls to the service.
For a catalog, course, line greeting, or voice menu, this is both cheaper in load and more stable in sound.
The choice of voiceover mode comes down to two questions: is the text known in advance, and is there a strict latency requirement. If the utterance is formed at the moment of response — streaming only. If it changes rarely — it's more efficient to prepare files once.
In practice, a hybrid more often works: constant phrases go into a fund of ready files, and the variable part — names, amounts, titles — is synthesized on the fly. We build this scheme in at the design stage so that latency and service load remain manageable.
Common technical concerns about speech synthesis
Concerns at acceptance usually relate not to sound quality but to how synthesis on Google Cloud Text-to-Speech behaves in emergency situations. Below is what we resolve before the start.
Where do texts go, and do they remain with the provider?
We synthesize only the needed fragment and cache the ready audio on our side — a repeated request does not leave the perimeter. We do not write logs with source texts, and keys are stored in secure storage.
Can access be separated by roles?
The editor works with texts and the pronunciation dictionary, the analyst sees statistics, and the administrator manages keys and limits. Permissions are checked on the service side; they can't be bypassed through the interface.
What happens if the synthesis service fails?
The request goes into a queue with a limited number of retries; during the fallback we serve a variant from cache. If the pause drags on, we switch to a backup engine: the scenario doesn't crash, and the dialogue continues.
How do you change the voiceover engine without losing the sound?
We store the pronunciation dictionary and tempo separately from the scenarios, so the transition is a configuration edit, not a rewrite of logic. We compare voices by blind listening on the same set of phrases.
Will we hit request limits?
We cut long scenes into fragments and cache them: repeating the same text doesn't consume quota. Under peak load, the queue smooths the spike, and we prioritize short utterances within the dialogue.
Let's discuss the task: we'll come back with an estimate and work plan
The accuracy of the voiceover task estimate depends on how complete the input data we see is.
A range of implementation timelines can be given even from a description, but a work plan with owners for each stage appears only after reviewing real texts, pronunciation requirements, and integration points.
To come back with an estimate and plan, it's enough to send:
- text examples — 10–20 utterances per role, must include complex cases: abbreviations, numbers, dates, amounts, names, titles;
- pronunciation glossary: terms and names that cannot be read "as written," with the desired stress;
- nature of the voiceover — how many utterances and their length, whether real-time response in dialogue is needed or pre-generation is suitable;
- voice requirements: language and region, tempo, style, number of voice actors, and role distribution;
- integration points — telephony, mobile app, web, call center — and in what form audio should be returned;
- constraints: what data cannot be sent to external services, and whether there is a requirement for re-generating the same text;
- acceptance criteria — how you will know the voiceover is ready, and who on the customer side approves the result.
We will review the examples, check the pronunciation of disputed words with selected voices, select a synthesis model in Google Cloud Text-to-Speech for your text profile, and come back with a plan: work stages, implementation timelines for each stage, team composition, and the owner for each stage. Describe the task — we'll come back with an estimate and work plan.