Audio formats¶

All output is mono at 24 000 Hz (sample_rate must be 24000 if given). The format field picks the container:

`format`	Content-Type	What you get	Use it for
`wav` (default)	`audio/wav`	RIFF/WAVE, 16-bit PCM	files, quick tests, players
`pcm16`	`audio/L16; rate=24000` style raw	signed 16-bit little-endian samples, no header	your own decoder/mixer, telephony bridges, browsers via Web Audio
`opus`	`audio/ogg; codecs=opus`	Ogg/Opus, 48 kbit/s, 20 ms packets, one Ogg page per packet	web playback, storage, WebRTC-adjacent pipelines

Streaming vs buffered¶

POST /v1/tts streams by default ("stream": true): chunked transfer, the first bytes after the first decoded 80 ms frame.

WAV while streaming carries a placeholder length in its header. Most players and ffmpeg handle it; strict parsers may not. Send "stream": false to receive a complete file with a correct length (and Content-Length).
Opus while streaming is a valid, growing Ogg stream; with "stream": false you get a complete, seekable file.
pcm16 has no header either way.

On the WebSocket there is no container for a message stream, so format: wav is downgraded to pcm16 (the start event tells you which format is in effect); opus sends Ogg pages as binary messages.

Converting¶

tts.sh

# WAV → MP3 / M4A
ffmpeg -i out.wav -c:a libmp3lame -q:a 3 out.mp3
ffmpeg -i out.wav -c:a aac -b:a 96k out.m4a
# raw PCM → 8 kHz μ-law for telephony
ffmpeg -f s16le -ar 24000 -ac 1 -i out.pcm -ar 8000 -acodec pcm_mulaw out.ul

Output chain¶

Since 2026-10-20 every stream passes through a small post-processing chain after the decoder, per request, before the encoder (postfx, default true). It does not touch the model; it makes the audio consistent across voices and safe to play loud:

Stage	What	Why
High-pass	DC blocker + 2nd-order high-pass at 70 Hz	removes the decoder's sub-bass rumble and offset, which only cost headroom
Loudness	per-voice gain so the first frame is already at level, then a slow BS.1770 tracker (gated, 1.5 s, ±4 dB) towards −16 LUFS	every voice and every utterance at the same perceived level; short replies rely on the per-voice gain alone, so nothing pumps
Fade-in	10 ms raised cosine on the first frame	no click when playback starts mid-waveform
Limiter	true-peak limiter at −1 dBTP, 4× oversampled, 1 ms look-ahead	the raw decoder exceeds 0 dBTP on about half of all sentences; codecs (Opus, μ-law, AAC) and D/A stages clip on inter-sample peaks

Latency: the limiter's look-ahead is the only delay, 24 samples (1 ms), inside the first 80 ms frame; the first bytes arrive at the same time as before. Send "postfx": false to get the decoder's untouched frames (for your own mastering chain or A/B tests).

"profile": "telephony" adds, before the loudness stage: a 300 Hz high-pass (the PSTN band starts there; low content only pumps the μ-law codec), a +3 dB presence band at 2.5–4 kHz (intelligibility through the 3.4 kHz roll-off) and a soft de-esser on 5–8 kHz (sibilance that aliases when you resample to 8 kHz). Use it when the audio goes to a phone call; for web, apps and recordings keep the default.

Pace¶

Pace is fixed per voice since 31 October 2026: female voices speak at their natural pace (1×), male voices at 1.15×, except mohit, manish and the four English (IN) male voices (1×). GET /v1/voices reports each voice's speed. A speed (alias pace) field in a request is accepted for compatibility and ignored. The pace is applied after the model (WSOLA, pitch unchanged): The model itself always speaks at the pace of its training audio, so the change happens after the decoder and before the output chain: a pitch-preserving time-stretch (WSOLA: 30 ms windows laid down every 15 ms, each read from where the waveform best continues the last). The voice and pitch stay the same; the duration becomes the natural duration ÷ speed.

`speed`	effect	measured (a 7.12 s Hinglish line)
`0.75`	slower, for elderly callers or dense numbers	9.49 s
`1.0`	natural pace (the audio is untouched)	7.12 s
`1.25`	brisker, for confirmations and repeat callers	5.70 s
`1.5`	fast	4.75 s

It streams like everything else: the stage holds back at most 42 ms of audio, inside the first 80 ms frame, so the first bytes arrive no later. Between 0.75 and 1.5 the stretch is hard to hear; towards 0.5 and 2.0 it starts to sound processed. It applies to every voice, Hinglish and English.

Frame timing¶

The engine produces audio in 80 ms frames (1 920 samples). The first frame is decoded alone, then frames are decoded four at a time, so after the first chunk audio arrives in ~320 ms steps that are each ahead of real time (real-time factor ≈ 0.14–0.19). Buffer ~100–200 ms before starting playback for jitter-free output over the public internet; see the streaming guide.