TTS Audio Downsampling for Telephony: G.711, 8kHz μ-law, and Carrier Audio Bridging

TLDR: Public switched telephone networks (PSTN) and SIP trunks still operate on the ITU-T G.711 standard, requiring 8 kHz audio companded as 8-bit $\mu$-law or A-law at 64 kbps. Meanwhile, state-of-the-art text-to-speech models output 24 kHz or 48 kHz linear PCM. When voice engineering teams connect modern TTS models to carrier telephony, crude downsampling introduces aliasing distortion, high-frequency spectral foldover, and 30ms to 80ms of filter delay. Bridging high-resolution neural speech into narrow carrier pipes requires purpose-built anti-aliasing filters, correct companding curves, and automated perceptual quality validation.
TTS audio downsampling for telephony is the systematic process of filtering, decimation, and companding high-sample-rate neural speech into carrier-compliant 8 kHz telecommunications formats. The core engineering challenge is preserving vocal clarity and consonant intelligibility across an audio passband restricted to 300 Hz through 3,400 Hz. Teams that treat telephony bridging as a generic format conversion ship muffled audio that fails caller comprehension benchmarks in production.
Modern voice AI agents rely heavily on telephony integration. Platforms like Twilio require media stream payloads formatted strictly as base64-encoded audio/x-mulaw at 8,000 Hz. Telephony bridges like FreeSWITCH, Asterisk, and carrier SIP trunks drop packets or fail connections when non-compliant payloads arrive. When building conversational AI voice agents, downsampling is not an afterthought; it is an active production quality gate.
Why Does Telephony Still Demand 8 kHz G.711 Audio?
Telephony networks still demand 8 kHz G.711 audio because global telecom infrastructure remains bound to legacy time-division multiplexing (TDM) and early digital voice trunk architectures established in 1972. Under the Nyquist-Shannon sampling theorem, an 8,000 Hz sampling rate accurately reconstructs acoustic frequencies up to 4,000 Hz. Because normal human speech energy concentrates between 300 Hz and 3,400 Hz, carrier standards standardize on 8 kHz channels to maximize voice call density over copper and fiber trunks.
The G.711 specification defines two primary logarithmic companding algorithms:
- $\mu$-law (PCMU): Standard in North America and Japan. It uses logarithmic quantization to compress 14-bit signed linear audio samples into 8-bit words.
- A-law (PCMA): Standard in Europe and international transit trunks. It uses a 13-bit linear to 8-bit logarithmic compression curve with slightly flatter dynamic range characteristics near zero.
Both formats operate at a fixed bit rate of 64 kbps (8,000 samples per second multiplied by 8 bits per sample). While WebRTC, mobile VoLTE, and modern conferencing protocols support wideband codecs such as Opus and G.722 at 16 kHz or 48 kHz, standard inbound customer service calls and outbound IVR dialers terminate onto PSTN networks that enforce G.711 narrowband constraints.
How Does Downsampling TTS Audio Create Severe Aliasing Distortion?
Downsampling TTS audio creates severe aliasing distortion when high-frequency energy above the 4 kHz Nyquist limit is not filtered out prior to decimation. When a neural model generates 24 kHz audio, acoustic frequencies exist up to 12 kHz. Fricative consonants like "s", "f", "sh", and "th" generate spectral energy peaking between 4,500 Hz and 8,000 Hz.
When naive decimation discards two out of every three samples to convert 24 kHz audio to 8 kHz without a steep low-pass filter, energy at 6 kHz reflects across the 4 kHz boundary and reappears as phantom energy at 2 kHz (calculated as $|8,000 - 6,000| = 2,000$ Hz). This spectral mirror effect is called aliasing.
In conversational phone calls, aliasing produces:
- Unnatural robotic buzzing and metallic ringing on every "s" sound.
- Phase smearing that makes whispered speech or natural breath pauses sound like line static.
- Severe degradation of ITU-T P.862 PESQ (Perceptual Evaluation of Speech Quality) scores, dropping objective MOS rankings from 4.2 down to 2.8.
To prevent aliasing, audio pipelines must pass high-resolution audio through a steep finite impulse response (FIR) low-pass filter with a sharp cutoff at 3.4 kHz before decimation. The filter must provide at least 60 dB to 80 dB of stopband attenuation at 4 kHz to silence out-of-band energy completely.
What Are the Performance Trade-offs Between Native 8 kHz Models and Real-Time Resampling?
Voice engineering teams face a fundamental architectural choice when connecting TTS to telephony trunks: configure the provider to emit native 8 kHz streams, or resample 24 kHz audio in the voice agent application layer.
| Provider / Model | Telephony Output Options | Native 8 kHz Support | Resampling Latency | Best Suited For |
|---|---|---|---|---|
| Cartesia | pcm_alaw, pcm_s16le at 8000 Hz | Yes (Dedicated acoustic decoders) | 0 ms (Server-side native) | Ultra-low-latency real-time voice agents |
| Deepgram Aura-2 | mulaw, alaw, linear16 at 8000 Hz | Yes (Direct telephony endpoints) | 0 ms (Server-side native) | Integrated STT + TTS conversational agent pipelines |
| ElevenLabs | pcm_8000, ulaw_8000, wav_8000 | Yes (API-level downsampling) | 10-25 ms | Expressive voice cloning and multilingual IVR |
| Google Cloud TTS | MULAW, ALAW_8000 | Yes (Standard telecom formats) | 5-15 ms | Large-scale enterprise GCP contact centers |
Requesting native mulaw or pcm_8000 directly from API providers eliminates client-side buffer management and avoids CPU-intensive DSP filtering on gateway servers. However, some providers execute basic linear interpolation behind their API endpoints rather than true polyphase filtering. Engineering teams must measure the actual frequency spectrum of vendor-provided 8 kHz audio using spectrum analyzers to verify that out-of-band harmonics are properly eliminated.
How to Build a Low-Latency Telephony Audio Pipeline
Building a production-ready carrier audio pipeline requires managing three pipeline stages: chunk buffering, filter convolution, and companding quantization.
1. Windowed Polyphase Resampling
When downsampling from 24,000 Hz to 8,000 Hz (a precise 3:1 integer decimation), implement a polyphase FIR filter. Polyphase decomposition divides filter coefficients into sub-filters, evaluating only the convolution sums required for emitted output samples. This reduces CPU usage by 66% compared to filtering the entire 24 kHz stream prior to decimation.
2. Audio Buffer Alignment
Telephony RTP packets typically transmit 20 milliseconds of audio per packet. At 8 kHz with 8-bit G.711 encoding, exactly 160 bytes represent 20ms of audio (8,000 samples/sec $\times$ 0.020 sec = 160 samples = 160 bytes). Upstream TTS streams must be chunked into sample counts divisible by 480 bytes at 24 kHz (480 $\div$ 3 = 160 samples at 8 kHz) to prevent packet fragmentation and jitter buffer stuttering.
3. Logarithmic Quantization and Dithering
When converting 16-bit linear PCM down to 8-bit $\mu$-law, apply triangular probability density function (TPDF) dither. Dithering randomizes quantization steps, turning harmonic distortion into low-level broadband white noise that human ears perceive as natural analog room tone rather than harsh digital clipping.
How Onepin Validates Telephony Audio Quality
Managing carrier audio standards across disparate voice models creates substantial maintenance overhead. When teams build voice bots across multiple TTS providers, format quirks and sample rate mismatches quickly cause production outages.
Onepin is a voice workflow platform that orchestrates, validates, and ships production-ready audio across 100+ TTS models. Instead of hand-coding DSP filters and debugging packet headers for each telephony trunk, Onepin automates format compliance, downsampling verification, and carrier quality scoring above the provider layer.
With Onepin, engineering teams define their delivery profile once, such as telephony-g711-mulaw-8khz, and Onepin automatically:
- Manages vendor-specific format parameters across providers like Cartesia, Deepgram, ElevenLabs, and Google Cloud Text-to-Speech.
- Applies polyphase anti-aliasing filters with strict stopband rejection when bridging high-sample-rate models.
- Validates that delivered audio buffers strictly conform to 20ms RTP frame boundaries.
- Scores telephony output against ITU-T speech intelligibility baselines before audio streams touch carrier trunks.
Explore the complete orchestration architecture and integration guides at onepin.ai/docs.
Frequently asked questions
- What is the difference between G.711 mu-law and A-law in TTS telephony pipelines?
- G.711 mu-law (PCMU) is the standard companding algorithm across North America and Japan, while A-law (PCMA) is standard across Europe and international networks. Both compress 16-bit linear PCM into 8-bit logarithmic samples at 8 kHz (64 kbps), but their dynamic range curves differ slightly.
- Why do high-fidelity TTS voices sound muffled or distorted over phone calls?
- Studio TTS models generate rich audio harmonics up to 24 kHz or 48 kHz. When downsampled to 8 kHz without steep low-pass anti-aliasing filters, frequencies above 4 kHz fold back into the audible spectrum as metallic ringing and phase distortion, severely degrading intelligibility.
- Should voice agent pipelines request 8 kHz native audio or downsample 24 kHz audio?
- Requesting native 8 kHz or telephony-encoded streams directly from providers with dedicated acoustic decoders eliminates client-side resampling latency and CPU overhead. When using models that only emit 24 kHz, use polyphase FIR filtering with an anti-aliasing cutoff at 3.4 kHz.
- How does Onepin handle telephony audio transcoding across TTS models?
- Onepin is a voice workflow platform that orchestrates, validates, and ships production-ready audio across 100+ TTS models. It automatically formats audio, provides carrier-grade resampling, checks PESQ speech quality standards, and routes verified G.711 mu-law or A-law streams directly to telephony providers.