SSE vs WebSocket for TTS

Both transports stream audio chunks as synthesis proceeds; they differ in connection lifetime and what your infrastructure tolerates. The rule of thumb: sockets for conversations, SSE for one-way streams, bytes for everything that is not live.

1 shape

the same request on every transport

The two wires, side by side

Same synthesis engine, same first-audio behavior, same request shape — the difference is entirely in what travels on the wire and how long the connection lives.

the actual wire — one SSE utterance, then one WS turn

# SSE — one HTTP response per utterance, no socket state
POST /v1/tts/sse
data: {"data": "<base64 pcm chunk>"}
data: {"data": "<base64 pcm chunk>"}
data: {"done": true, "ttfa_ms": 107, "audio_ms": 2810}

# WebSocket — one socket per call, an utterance per turn
--> {"text": "…", "lang": "en", "voice_id": "caller-42"}
<-- <binary pcm frame> <binary pcm frame> …
<-- {"ttfa_ms": 107, "audio_ms": 2810}

Choose by connection shape

WebSocket (wss://tts.gandr.ai/ws): a socket amortizes connection setup across a whole call, which matters when every turn pays the latency budget — and barge-in is one message on an open socket.
SSE (POST /v1/tts/sse): pays HTTP setup per utterance but needs no connection management at all. Proxies and serverless platforms that buffer or kill long-lived sockets handle SSE fine.
One-shot bytes (POST /v1/tts/bytes): a complete WAV in one response, for reminders and prerendered prompts — not a stream at all.

Related sheets.

glossary

~100 ms

Streaming text-to-speech

Streaming TTS returns audio in chunks as synthesis proceeds instead of one file at the end. Why voice agents require it, and what to check in a streaming API.

glossary

×2

Barge-in

Barge-in is the caller interrupting the agent mid-sentence. What the TTS layer must do to support it: stop instantly, resynthesize fast, stay cheap.

capability

107 ms

Streaming synthesis that keeps up with a call

Chunked PCM from the first hundred milliseconds: SSE and WebSocket streaming TTS measured at 107 ms to first audio on the production API.

Every term on this page is measurable on a live call — watch the readout while your own script synthesizes.

See the measured figures live