Choosing TTS for Phone Calls: 8kHz Reality vs. Studio Demos

Every TTS vendor demo plays back at full bandwidth through your laptop speakers or a good pair of headphones. Your callers hear the same voice through 8kHz narrowband telephony audio, compressed by a codec, possibly relayed through a cellular network, and played through a phone speaker that costs a few dollars. The voice that wins the demo is not reliably the voice that wins on an actual call, and most teams never test the gap before signing a contract.

What 8kHz telephony actually does to a voice

Standard telephony audio samples at 8kHz, which caps the frequency range at 4kHz — roughly half the range of the 16kHz+ audio most TTS demos and quality benchmarks use. That missing upper range carries a lot of the detail that makes a voice sound natural: sibilance, breathiness, the harmonic texture that distinguishes a warm voice from a thin one. On top of the bandwidth cut, most calls also pass through a lossy codec (commonly G.711, sometimes more aggressive ones on cellular or VoIP hops), which introduces its own compression artifacts.

The practical effect: voices that sound rich and natural at full bandwidth can come out thin, slightly robotic, or harder to understand at 8kHz — and the amount of degradation isn't uniform across providers or even across voices from the same provider. A voice tuned for warmth and breathiness on wideband audio can lose exactly the qualities that made it sound good, while a flatter, more consonant-forward voice might degrade less because there was less high-frequency detail to lose in the first place.

Test at 8kHz, not at demo quality

This is the single highest-leverage thing you can do before choosing a TTS provider: don't evaluate the raw API output. Take generated samples, run them through the actual codec your telephony path uses (G.711 is a reasonable default to test against if you don't know your exact path yet), and listen to — or better, run intelligibility tests on — the downsampled result. The vendor comparison you get from this is often meaningfully different from the comparison you'd get listening to raw samples in a browser tab.

If you can, test with your actual SIP trunk or telephony provider in the loop rather than just a codec simulation — some providers apply additional processing (echo cancellation, noise suppression, jitter buffering) that interacts with synthesized speech differently than it does with human speech, since TTS output doesn't have the same acoustic characteristics microphones capture from a room.

Latency is part of "best," not a separate tradeoff

For a conversational voice agent, time-to-first-audio-byte matters as much as voice quality — a beautiful voice that takes 800ms to start speaking after the LLM produces text will feel sluggish regardless of how natural it sounds once it starts. Streaming TTS (synthesizing and sending audio in chunks as text arrives, rather than waiting for the full response) is close to mandatory for real-time conversation, and not every provider's highest-quality voice tier supports low-latency streaming — sometimes the best-sounding voice and the fastest-starting voice are different SKUs from the same vendor.

Budget this explicitly: know your total latency budget for the turn (see our note on voice AI's roughly 500ms perceived-delay threshold), and treat TTS time-to-first-byte as a hard constraint you filter providers by, not a nice-to-have you compare after picking on voice quality alone.

Consistency matters more than it sounds

A subtler failure mode: some TTS systems introduce small variations in tone, pacing, or pronunciation between calls, or even between turns in the same call, especially for providers using more generative/less deterministic synthesis approaches. For a brand voice, this is a real problem — callers who interact with your voicebot repeatedly will notice if it sounds like a slightly different person each time, in a way that reads as unpolished even if each individual sample sounds fine in isolation. If consistency across calls matters for your use case, test for it explicitly by generating the same script multiple times and comparing, not just testing variety.

SSML control is a real differentiator, not a checkbox

Natural phone pacing depends on pauses, emphasis, and pronunciation control that generic TTS output often gets wrong for domain-specific terms — account numbers, product names, acronyms. Providers vary a lot in how well their SSML (or equivalent control) support actually works in practice versus what's documented. If your content includes a lot of domain vocabulary or numeric data that needs to be read a specific way (currency amounts, phone numbers, dates), test pronunciation control as part of evaluation, not as an afterthought once you've already committed.

There's no single "best" — there's a best for your constraints

The honest framework: rank providers separately on (1) intelligibility and naturalness after your actual codec path, (2) streaming latency against your budget, (3) cross-call consistency, (4) domain-vocabulary and SSML control, and (5) cost per character or minute at your expected volume. The provider that wins on raw demo quality frequently isn't the one that wins once you weight for these five, and the right choice depends on which of them matters most for your specific deployment — a low-latency support bot has different priorities than a long-form IVR announcement system.

This connects directly to the accuracy testing discipline we cover for ASR in contact centers — the same principle applies in both directions: test the technology in the actual acoustic conditions it'll run in, not the conditions the vendor demo was built for.

If you're mid-evaluation and want a second opinion on which providers actually hold up under your real telephony conditions, get in touch.