Streaming
First audio in a few hundred milliseconds. Stream by default.
How it works
Set stream: true on POST /v1/audio/speech and the server returns audio in a chunked HTTP response as it’s generated, rather than buffering the whole clip first. For anything longer than a sentence this is the difference between “instant” and “broken”. Stream by default. (If you’re feeding text in incrementally, for example from an LLM, use input streaming over WebSocket instead.)
Formats & latency
pcm is the lowest-latency path: headerless 16-bit LE mono at your sample_rate (24 kHz default), playable the instant bytes arrive. Compressed formats (mp3, opus) stream too, but add a little container overhead.
GET /health: the engine and stream_formats fields tell you exactly what the current deployment streams. Don’t assume; read it.Browser playback
Two approaches depending on format. For pcm, queue decoded buffers onto an AudioContext with a small (~150 ms) jitter buffer:
Native & server playback
On native platforms, request pcm and write bytes to your audio sink as they arrive; first bytes land in a few hundred milliseconds on GPU serving. Re-align to 2-byte frames across chunk boundaries (a chunk can split a sample).
Telephony
For phone systems, request companded 8 kHz audio directly; no transcoding step in your media server:
{ "response_format": "ulaw", "sample_rate": 8000 }: North American / μ-law{ "response_format": "alaw", "sample_rate": 8000 }: European / A-law
Resampling runs in-process and scales: 8 kHz streams are cheap, so this fans out to many concurrent calls.