Loading...
HD TTS models exist. HD delivery is the hard part. Most voice AI sounds robotic because the network crushes audio before customers hear it.
Your TTS model generates HD audio. The phone network crushes it to 8 kHz.
Customers hear a robot.
With the TTS market projected to reach $9.36 billion by 2032, much of that spend could go toward voice quality that never reaches the customer.
HD TTS isn't about the model. It's about infrastructure that gives HD audio the best chance of surviving the call path.
This article covers how HD TTS actually works, what breaks it, and how to set up voice AI that sounds the way it should. First: why most HD audio never reaches the customer.
Related articles
There's a gap between what TTS models produce and what customers hear.
Modern neural TTS models generate 24 kHz audio by default. That's high enough fidelity to capture human-like nuance: breathing patterns, emotional inflection, natural pauses. Models like Kokoro v1.0 hold a 44% win rate in blind tests. Higgs Audio V2 trains on over 10 million hours of speech. The synthesis quality is there.
We often obsess over LLM inference speeds, but in Voice AI, the network is often the silent killer.
Ian Reither, COO, Cofounder @ Telnyx
The problem is delivery. PSTN calls use G.711, which samples at 8 kHz. That's the native format for traditional telephony. When your 24 kHz TTS output routes through PSTN, it gets downsampled to 8 kHz before the customer hears it. The breathing disappears. The inflection flattens. The nuance is gone.
You can't force HD on every call. You can build a stack that preserves it whenever the path supports it.
HD TTS depends on the call path, not just the model. Here's what matters:
No platform can guarantee HD end-to-end when PSTN is involved. But the right infrastructure maximizes the odds.
Voice selection matters, but it's not where most deployments fail. The model you choose is just one step. Whether that voice reaches customers at full fidelity depends on everything downstream.
That said, picking the wrong voice creates problems no infrastructure can fix. Here's what to test:
You've picked the voice. What happens next depends on codec selection, media routing, and monitoring.
HD voice depends on codec selection, latency, and real-time monitoring. These three docs cover the technical controls that matter.
| Optimization | Doc |
|---|---|
| Set preferred codecs | Pass preferred_codecs to force Opus or G.722 over G.711. The WebRTC JS SDK and iOS SDK both support codec prioritization at call creation. |
| Anchor media to the nearest PoP | Set anchorsite_override to Latency for automatic lowest-RTT routing, or hardcode a specific PoP like Frankfurt, Germany. Configure this when creating your credential connection. |
| Debug call quality | Query the Detail Records API to analyze call performance across SIP trunking, Voice AI, and WebRTC. Filter by record_type to isolate TTS or STT issues. |
You can tune codecs and anchor media all day. But if your TTS runs on GPUs in Virginia and your telephony PoP sits in Frankfurt, physics wins. The speed of light doesn't care about your optimization checklist.
Telnyx provides the infrastructure that makes HD TTS delivery practical at scale:
Ready to test HD TTS with your specific requirements? Explore Telnyx Voice AI Agents to experience production-ready performance with your actual customer support scenarios.