Choosing between synthesized and pre-recorded speech affects far more than voice quality. It changes what your voice product can say, how quickly it can respond, how safely teams can update it, and what happens when a dependency fails. The right design starts with the content each utterance must carry and the conditions under which people hear it.
The practical answer: compare live generation with fixed playback
Choose by utterance. Use live text-to-speech (TTS) when the system must compose spoken content during the interaction. Use a fixed audio file when the wording is stable and the exact performance or approved rendering should repeat. Use both when one product has dynamic conversation and fixed prompts.
Two separate choices are involved:
- Speech source is who or what created the voice. It may be a human actor or a synthesis model.
- Delivery method is when the audio is produced. Live TTS generates it at runtime. Fixed playback selects a file created earlier.
A synthetic voice can therefore be pre-recorded. For example, a billing agent might play an approved opening disclosure recorded by an actor, then use live TTS to say, “Your current balance is eighty-two dollars and thirteen cents.” The fixed disclosure could also be pre-generated with the same synthetic voice. The useful comparison is live TTS versus fixed human-recorded or pre-rendered audio.
Live TTS vs. pre-generated TTS
Live TTS turns the response text into audio during the session. Some systems stream playable audio as it becomes available. Others wait for a larger segment or a complete rendering. This path covers text that was unknown before the interaction, with runtime synthesis latency and another live dependency.
Pre-generated TTS renders synthetic speech before deployment and stores the result as an audio file. At runtime, it behaves like other recorded voice prompts: the application selects and plays an existing asset. It retains consistent wording and removes live synthesis from that moment, but file lookup, decoding, buffering, network transport, and telephony still take time.
Voice realism does not decide between these paths. A 2025 controlled study tested selected one-sentence clips from one voice-cloning system. The researchers screened, regenerated, and edited the human and synthetic stimuli to remove obvious artifacts. In one combined condition, listeners labeled the voice-clone clips as human about as often as the human clips. Their discrimination remained very low but statistically above zero. That result applies to selected, edited short clips. It does not establish that every TTS voice sounds human or that the same result holds in a live phone call.
The key variable is response variability, or how many valid versions of an utterance the system may need. A fixed opening notice has low variability. A response that combines an account balance, a date, a customer name, and a follow-up question has high variability. Producing a fixed file for every high-variability response is usually impractical.
| Decision factor | Live TTS | Fixed audio: human-recorded or pre-generated TTS | Hybrid design |
|---|---|---|---|
| Speech source | Synthetic | Human or synthetic | Chosen per utterance |
| Response coverage | Generates new wording at runtime | Limited to assets produced in advance | Sends dynamic turns to live generation and stable prompts to files |
| Time to change | Change text or configuration, then test | Record or render, edit, approve, encode, and deploy a new asset | Depends on which path owns the utterance |
| First-audio latency | Includes runtime synthesis; streaming can reduce the wait when the provider and runtime support it | Avoids synthesis at runtime, though asset delivery still adds latency | Fixed audio can reduce startup work; live turns still depend on generation |
| Delivery control | Voice settings, punctuation, lexicons, and markup provide control, with results varying by model | Actor performance and editing give precise control over one asset; pre-generated TTS preserves an approved render | Fixed control for selected prompts plus broader conversational coverage |
| Pronunciation | Must be tested on names, codes, dates, and domain terms | Approved pronunciation stays fixed until the asset changes | Reserve fixed assets for invariant phrases that resist reliable live synthesis |
| Localization | Each language needs text, a suitable voice, and linguistic testing | Each language needs a separate performance or rendering plus asset management | Apply an explicit routing policy per locale |
| Failure mode | Provider errors, timeouts, malformed output, or slow generation | Missing, stale, corrupt, or incorrectly selected assets | More paths to observe, version, and test |
| Ongoing cost | Usage fees plus engineering and quality work | Talent or rendering, editing, storage, and every revision cycle | Higher routing complexity, sometimes lower content-production burden |
In Dasha, configured TTS handles live agent speech. Our documentation verifies fixed audio through pre-conversation media: when enabled, an uploaded file plays once as the call connects and cannot be interrupted. That feature covers call-start media only. It does not document arbitrary mid-call file playback or an automatic fallback when TTS fails.
We keep the live conversation in our managed runtime so teams can inspect transcripts, model interactions, tool calls, and timing together. Call recordings are available only when recording is enabled. If a product only plays a fixed menu and never composes responses, a simple player and deterministic call flow may be easier to operate than a live voice-agent runtime.
Where each approach fits
Fixed prompts and branded audio
Fixed audio fits short, stable moments that justify careful production. Examples include a sonic logo, brief welcome, hold audio, or approved recorded voice prompt. A human recording gives the producer direct performance control. Pre-generated TTS can preserve the voice identity used elsewhere in the product without calling the synthesis service at playback time. Live TTS is useful when even the greeting changes by account, campaign, or conversation state.
Fixed playback removes synthesis time from that moment, rather than removing all delay. The runtime must still retrieve, decode, buffer, and deliver the asset.
Version each file with the flow that selects it. Track the locale, script, speaker or voice license, approval, encoding, loudness target, and retirement date. A polished file becomes a liability when the application plays it in the wrong market or after the underlying policy changes.
Disclosures and approved wording
A fixed human recording or pre-generated TTS asset is a strong candidate for an invariant disclosure because the team can approve exactly what will play. Live TTS may still be appropriate when the required wording varies by jurisdiction, product, or caller state and a complete asset set would be difficult to maintain.
The file alone does not make the implementation compliant. The product still needs the right script, jurisdiction, timing, proof of playback, retention policy, and interruption behavior for its use case.
Treat each fixed disclosure as a controlled release artifact. Hash it, tie it to a script version, log which version played, and define what happens if playback fails. If the notice must complete before interaction begins, make that an explicit state in the call flow.
Dynamic account data and transaction results
Live TTS is usually the practical path for values drawn from a broad or changing range, including balances, appointment times, order states, names, addresses, confirmation numbers, and tool results. A small bounded vocabulary can use fixed clips, but concatenated fragments often create audible changes in pace, level, and prosody. The asset count and selection logic also grow quickly.
Normalize data before synthesis. A language model should not decide on its own how to read a currency amount, ambiguous date, or alphanumeric code. Convert the value into an explicit spoken form, then send that text to TTS. Speech Synthesis Markup Language (SSML) defines standard concepts for pronunciation, prosody, breaks, and interpreting structured text, although provider support varies. The SSML specification is a useful model for separating written data from intended speech.
Live conversational turns
In Dasha's live-TTS architecture, open-ended agent turns use synthesized speech because the spoken response depends on caller language, conversation state, retrieved data, tool output, and the caller's latest correction. Fixed assets can still own stable call-start prompts.
Native audio-to-audio agents also exist. They can generate response audio without exposing a separate TTS stage. Their output belongs on the live-generation side of this comparison because the audio is created for the current turn, rather than selected from a fixed library. The architectural tradeoffs between direct audio and an explicit STT, model, and TTS cascade are covered in our guide to speech-to-speech models.
For live generation, optimize the whole turn. The caller experiences the gap after speaking, the first audible response, interruption behavior, pronunciation, and whether the agent completes the task. Naturalness is only one acceptance criterion.
Long-form narration
Either delivery method can work for long-form audio. Choose an actor when performance is part of the product and the material will remain stable. Choose pre-generated TTS when the script is stable at playback time but recording operations would dominate the release cycle. Choose live TTS when narration must be composed or personalized close to delivery, accepting the additional runtime dependency.
Long speech inside a live call is usually a content-design problem first. Break explanations into short units, let the listener steer, and provide another channel for dense material. A convincing voice does not make a long monologue easier to retain.
General design guidance: fallbacks and degraded operation
This section describes a general voice-system pattern, not a documented Dasha feature. Dasha's current documentation confirms call-start pre-conversation media only. It does not confirm arbitrary mid-call playback or automatic TTS-failure fallback.
In systems that support runtime file playback, a fixed recovery recording can provide a narrow fallback when it has been configured and enabled. It can acknowledge a technical problem, offer a transfer, or close safely. It should never imply that a failed transaction succeeded.
A defensible failure path can:
- Set a deadline for first audio and completion of live generation.
- Cancel late audio so it cannot play after the conversation has moved on.
- Play an enabled fixed recovery message when the runtime supports that action.
- Transfer, retry, or end according to the workflow's risk.
- Record the failure with provider, voice, locale, text, and timing metadata.
The hidden cost is operations, not audio generation
The useful cost comparison is the cost of a safe change over the product's lifetime.
For human-recorded speech, count script review, talent, studio time, pickups, editing, localization, asset storage, deployment, and consistency across sessions. A one-line policy change can reopen the entire chain.
For pre-generated TTS, talent and studio work may disappear, but rendering, listening review, rights, asset versioning, and deployment remain. It shares the fixed path's maintenance burden even though its source is synthetic.
For live TTS, count usage, integration, dictionaries or normalization rules, model changes, provider limits, regression testing, failure handling, and production review. A text edit is cheap to make and can still break pronunciation or turn timing.
For hybrid systems, add routing and versioning. Every utterance class needs an owner, delivery path, locale policy, failure behavior, and observability path. The architecture earns its complexity when fixed playback protects a genuinely stable experience or live generation covers response variability that files cannot manage.
Voice rights also belong in the design. A recording license does not automatically grant the right to train or operate a voice clone, and a synthetic voice contract needs defined uses and controls. At minimum, record consent, intended channels, regions, term, permitted content, training rights, revocation terms, storage, and what happens to generated assets after termination. Current SAG-AFTRA agreements emphasize consent, compensation, and control for digital replicas. Your own terms need review for the people, markets, and content involved.
How to compare the options in your real call path
A studio sample or provider demo leaves out the runtime, phone network, and conversation policy. Compare complete calls over every channel you plan to ship.
1. Build a representative utterance set
Include:
- fixed greetings, recorded voice prompts, and disclosures;
- common short confirmations;
- names from each target market;
- street addresses and company names;
- currencies, decimals, dates, times, phone numbers, and alphanumeric IDs;
- negative or sensitive messages that require controlled delivery;
- long sentences and short fragments;
- tool results with missing, malformed, and unusually long values.
Keep the script and voice identity as consistent as the comparison allows. Otherwise, you may be testing copy quality, acting direction, or speaker preference instead of delivery method.
2. Test the actual acoustic channel
Run browser and phone tests separately. Include background speech, road noise, packet loss, low volume, speakerphone, and common headset conditions. Listen to the audio that reaches the user, rather than the original file or provider response.
Test transitions between live and fixed paths. Match loudness, pace, perceived distance, and voice identity. If switching is obvious, move the boundary between utterances or pre-generate fixed audio with the same synthetic voice. Avoid stitching live and fixed audio inside one sentence unless listening tests show that the seam is acceptable. Earlier human-factors research on rapidly alternating recorded and synthetic segments found that listeners preferred a consistent voice, which supports testing continuity instead of assuming it.
3. Exercise timing and interruption
Measure live generation during normal turns, hesitation, interruption, correction, and silence. A fixed asset also needs an explicit interruption policy. If callers cannot interrupt it, keep it short and reserve that behavior for content that must play as one unit.
Track the acoustic end of the caller's turn to the first audible agent speech at the median and 95th percentile. Separate end-of-turn detection, model generation, tool time, TTS generation where applicable, asset retrieval, buffering, and transport. Our guide to voice AI latency explains why one average hides the slow calls people remember.
4. Score comprehension and task outcomes
Use blind listening tests for pronunciation, intelligibility, voice continuity, appropriateness, and preference. Mean opinion score can summarize subjective quality, but it cannot tell you whether the caller understood an amount or completed the task.
Add task measures:
- correct repetition of names, amounts, dates, and codes;
- successful confirmations and tool actions;
- clarification, transfer, and abandonment rates;
- interruptions where playback stops as intended;
- failures recovered without a false success claim;
- time and effort needed to ship a script change;
- incidents caused by a stale or wrong audio version.
5. Set release gates by utterance class
Do not approve one voice once for every use. A live TTS configuration can pass greetings and fail serial numbers. A fixed file can sound excellent and still be impossible to maintain across locales.
Create separate gates for fixed, templated, dynamic, sensitive, and recovery speech. Keep the representative set as a regression suite whenever the voice, provider, script, runtime, asset library, or telephony path changes. The same discipline should extend to the rest of your voice-agent testing.
A production rule that scales
Make two decisions for each utterance: where the speech comes from and when its audio is produced. Default to live generation for high-variability conversation. Add human-recorded or pre-generated files where repeatable delivery justifies a fixed asset. Keep source changes between utterances, version each script and file together, and evaluate the complete path through the real channel.
If you want to run a live-TTS design without assembling the real-time voice stack yourself, start building with Dasha and test your call-start media, synthesized turns, interruption behavior, and failure handling in one managed runtime.
