SaluteSpeech TTS: where speech synthesis breaks in a product
Speech synthesis breaks not in a demo but under live traffic.
Audio is not generated instantly, and when several dozen users open a product card or start reading a long document at the same time, requests queue up: voicing latency grows to several seconds, and playback cuts a phrase off mid-word.
To the interface it looks like random glitches; to the user it looks like text-to-speech that simply does not work.
Another class of failures is pronunciation. SKUs, abbreviations, Latin script, and numerals are read out letter by letter or with the wrong stress, and instead of normal speech you get a robotic voice.
Teams start fixing this by hand: recording dictionaries, greetings, and individual lines, even though with proper configuration such cases are covered by reading rules and stress placement.
The most expensive failure is the unavailability of the external synthesis service. If audio is requested on the fly and without a reserve, the product goes completely silent: the screen works, the sound does not.
This is solved by pre-generating frequently requested fragments, storing ready-made tracks bound to the text and the selected voice, and having a clear degradation path for when synthesis is unavailable. Let us break down how this is solved for each class of failure.
What managed speech synthesis delivers: speed and stability
Speech synthesis in a product is not a single call but a pipeline: the text is split into phrases, sent off for voicing, and the returned audio is cached by the hash of the string.
SaluteSpeech TTS is responsible for the voice in this scheme, while the logic of retries, priorities, and substitution stays on our side. That is why synthesis quality stops depending on which scenario the user opened first.
A single product voice rests on a shared pronunciation dictionary and a set of intonation templates. A term, abbreviation, or tariff name is fixed in one place and changes across all scenarios at once — with no need to re-record every block with a voice actor.
Preparing new speech material shrinks from days to hours: editing the text and re-generating instead of a studio session.
Response time is constrained not by synthesis itself but by waiting for a complete track. We deliver sound as a stream, phrase by phrase as it becomes ready: the user hears the first line within fractions of a second while the rest is still being synthesized.
Frequent hints, greetings, and system messages are pre-generated and sit in the cache — their response is nearly instant.
The load on the voicing service is smoothed by a priority queue and a cap on concurrent requests: interactive lines go first, background batch voicing follows. A retry after a failure does not duplicate fragments that are already ready — it only fills in the missing ones.
Together this eliminates the class of failures where "there is no sound because of an external service timeout": the scenario degrades to a text response but does not break.
The share of scenarios with automatic voicing reaches full coverage where previously some screens had no voice at all.
Synthesis modes: streaming, batch voicing, hybrid scheme
Synthesis via SaluteSpeech TTS runs up against not the quality of the voice but the mode of text delivery.
If the initiator is a user in a dialogue, you cannot wait for the whole reply to be voiced; if the system is voicing an array of documents, it matters more to load the queue evenly and not keep the connection open.
That is why one integration usually hosts three modes, and we pick them to fit the scenario rather than by default.
| Option | When it fits | Limitations |
|---|---|---|
| Streaming synthesis | Replies in a dialogue, voice bot, in-interface hints: sound is needed before the whole text is ready | A dropped connection cuts the phrase short — a buffer and re-sending of the tail are needed; it is harder to compute the length of the pause between lines |
| Batch voicing | Large volumes: regulations, catalogs, training courses, overnight exports | The result is delivered only in full after the queue is processed, there is no interactivity, and editing a single fragment re-runs the entire text |
| Hybrid scheme | A dialogue with recurring phrases: greetings, statuses, errors, short replies | A pre-recording layer and an invalidation rule are needed: change the template — rebuild the recording, otherwise the customer will hear the old wording |
In practice, pure streaming is rare: a dialogue consists of recurring phrases three quarters of the time. We move them into pre-recorded audio — the key becomes the text together with the voice and rate, and when a template is edited the recording is rebuilt.
Streaming synthesis remains for non-repeating fragments, batch — for overnight exports. The logs show the share of replies served from pre-recordings and the time to first sound — that is the basis for tuning the mode to the load.
Implementing SaluteSpeech TTS: stages of engineering work
Before launching speech synthesis, we analyze what the system says out loud: the length of the lines, their frequency, latency requirements, and the acceptable quality on different channels — a phone line and an in-hall speaker sound different.
This determines the call scheme for SaluteSpeech and which phrases we prepare in advance and which we serve on the fly.
- Scenario audit. We collect all the lines of the voice menu, bot, or announcement voicing, split them into static and dynamic, and fix the response requirements.
- Integration scheme. We define the call points and the behavior when synthesis is unavailable — a fallback phrase instead of a broken dialogue and a lost request.
- Pronunciation setup. We maintain a substitution dictionary: abbreviations, numbers, dates, names, proper names, stress in homographs. Every rule is tested on reference phrases.
- Pre-generation and streaming delivery. Static phrases are synthesized once and stored ready-made; dynamic ones are streamed so the caller does not wait for a full assembly.
- Load testing. We run peak scenarios and failures: we measure the time to first sound, the share of successful responses, and queue growth at peak.
- Solution acceptance. We listen to a control set of texts together with the client, check intonation and pronunciation, and fix the list of edits.
- Handover to operations. We deliver the configuration, pronunciation dictionary, integration scheme, and procedure: how to add new phrases and what to do in case of a failure.
Handover package: configurations, schemes, procedures
We hand over not a "working service" but a kit that lets your engineer or our support team evolve speech synthesis without digging through someone else's code.
The package contents are fixed at the start of the SaluteSpeech TTS integration and refined for your processes — below is what is included by default.
- Service configurations. Connection profiles, the voice set, rate and timbre, request length limits, and rules for splitting long texts into fragments. It is marked which parameters can be changed without a rebuild.
- Integration scheme. The path of the text from the source (website, database, queue) through normalization to the finished audio and its storage location. Failure points, retries, and timeout behavior are marked.
- Access rules. Environment separation, key permissions, secret rotation, request rate limits, and the procedure in case of access compromise.
- Pronunciation dictionary. Abbreviations, brands, names, and numerals with reference pronunciation: what is spelled out letter by letter, what is read as a word, where a pause is needed. It eliminates the main cause of "robot" complaints without code changes.
- Update procedure. How a new version of the voice or settings is released, what checks run before rollout, and how to roll back to the previous set if the sound has changed.
- Support instructions. A diagnostic tree for typical tickets: no sound, truncated fragment, wrong stress, external service failure.
- Documentation. Interface descriptions, request examples, a checks checklist, and an acceptance protocol with an agreed list of voices.
We keep the artifacts next to the code so that the description does not diverge from the actual behavior of the service.
At acceptance we go through the list together with your team: the package is either accepted or sent back for revision — with no verbal agreements that get lost a month later. Describe your task, and we will fix the package contents for your environment.
Case study: a support service voice assistant built on speech synthesis
Before implementation, voicing in support relied on template phrases: the agent picked a suitable one and said it themselves. The share of scenarios where the answer was voiced automatically did not exceed a quarter — anything beyond the tariff reference went to a live agent.
During peak hours the load on the shift grew along with the queue, and the time to prepare a new speech block was measured in days: recording, mixing, uploading files into the scenario.
Typical answers were moved to synthesis: a line is assembled from the knowledge base, and the agent joins in where a specific situation needs to be handled.
We connected SaluteSpeech TTS — the speech block became not a recorded file but a line of text and a set of rules for pronouncing it. A new block is prepared by editing the wording, with no studio session and no scenario rebuild.
What changed after the move to synthesis
- The share of scenarios with automatic voicing grew from a quarter to four fifths — the queue for an agent shrank by the same factor.
- Preparing a new speech block — from several days down to an hour: edit the text, check the pronunciation, publish it into the scenario.
- Tickets about sound quality dropped roughly threefold after we built a pronunciation dictionary for abbreviations, tariff names, and numbers.
Controlled degradation was addressed separately: if synthesis is unavailable, the scenario follows standard routing to an agent, and the caller does not hear a broken phrase.
This fallback is exercised in load tests before every knowledge base update — the support voice assistant remains predictable under any load.
What to do if speech synthesis is already deployed on another service?
Migrating to another synthesis engine is not about rewriting scenarios but about running two environments in parallel and switching traffic in a controlled way.
We start with an inventory: which scenarios call synthesis, which voices and output formats are used, where ready-made phrases are cached, and whether there are manual pronunciation edits. Without this inventory, migration turns into guesswork.
The synthesis call is moved behind an adapter: the application passes text and parameters, and the provider is selected by configuration rather than by editing code in ten places.
A separate task is markup: different services read pauses, stresses, numbers, and abbreviations in their own way. Pronunciation dictionaries and lexicons are transferred and tested on real texts, otherwise the voice will stumble on terminology.
Before switching, we launch a parallel environment: the same corpus of phrases is run through the previous service and through SaluteSpeech, and we compare duration, joins, and intonation in questions and enumerations.
Discrepancies are compiled into an edit table — it is immediately clear what can be fixed by configuration and what requires text edits. We look at edge cases separately: long paragraphs, Latin script, digits, links.
Traffic is switched gradually — first service scenarios, then a share of production requests, then scenario by scenario. The switch is kept in configuration, so a rollback takes minutes and does not require a new release.
The previous environment stays live until the new one passes the same checks: matching pronunciation of key terms, no truncation on long phrases, and stable response under load.
Technical concerns: voices, limits, data privacy
SaluteSpeech TTS is cloud speech synthesis, and almost all technical concerns around it boil down to four topics: whether the voice is controllable, what happens at load peaks, where the texts go, and how terminology sounds.
Some of the limitations are removed by preparation: pronunciation dictionaries, stress and pause markup, a glossary of abbreviations. Below are answers to the questions engineering teams ask most often.
Can a custom voice be created?
Yes, from a studio recording of a voice actor: clean material without noise, overlaps, or reverb, usually several hours of reading.
We prepare the dataset, annotate it, train the model, and submit samples for acceptance — only after that does the voice go into the product and not get mixed up with the standard ones.
What happens if the synthesis service is unavailable?
Long texts are synthesized in advance and served from prepared storage; short lines are requested on the fly. When rate limits are exceeded and when the timeout expires, a retry with increasing backoff kicks in, followed by a fallback voice. The user hears a pause, not a failure.
Where do the texts go and who has access to them?
Texts are transmitted over a secure channel, access is restricted to a service account, and the logs store metadata rather than content. For sensitive scenarios we deploy synthesis in the customer's closed environment — the data never leaves the perimeter.
Are terms and abbreviations intelligible?
By default, Latin script, SKUs, and abbreviations are read inaccurately. We create a pronunciation dictionary: how to read an abbreviation, where to place the stress, where a pause is needed.
Then we run the texts through quality control — by ear and by reverse speech recognition — so that discrepancies are visible before release.
Let's discuss your task: speech synthesis for your scenario and load
To come back with an estimate for a speech synthesis project, we need not a general idea but the working parameters of the scenario. We gather them in one conversation — without ten-page questionnaires and a week of clarifying emails.
- Examples of real phrases: agent lines, announcements, bot replies — a hundred or so lines straight from your system.
- Voices and roles: how many voice actors are needed and what delivery — neutral, emotional, with a distinctive timbre.
- Channels: telephony, web widget, mobile app, an on-site station — where exactly the synthesis is heard.
- Load: the average and peak number of requests per minute, line length, and the response latency requirement.
- Environment constraints: where personal data may be processed, and what is required for storage and logs.
In return you get a staged implementation plan and a pilot launch procedure: first a run on your corpus of phrases, then acceptance based on intelligibility and the error rate on abbreviations and names, and only after that production rollout.
We run synthesis on SaluteSpeech TTS in the same order — first an isolated environment, then production traffic.
Scope and timelines are fixed in the plan before the integration starts. Describe your task and send examples of texts — we will come back with an estimate and a work plan.