Streaming
Streaming TTS delivers audio chunks as they’re generated - playback starts immediately instead of waiting for the full file. First chunk arrives in ~100ms.
Streamed audio output:
WebSocket Streaming
Persistent connections for continuous, low-latency audio. Best for conversational AI and real-time apps.
Endpoint: wss://api.smallest.ai/waves/v1/tts/live
Pass word_timestamps: true on the WebSocket request to receive per-word timing events (status: "word_timestamp") interleaved with the audio chunks - useful for live captions, karaoke-style highlighting, and avatar lip-sync. Words come back verbatim from the input text ("$100" stays "$100", not normalized). Supported on English + Hindi base-queue voices. See Word-level timestamps on the Lightning v3.1 model card for the wire shape, voice support matrix, and a worked example.
SSE Streaming
Server-Sent Events over HTTP - simpler to set up, no persistent connection needed.
Endpoint: POST https://api.smallest.ai/waves/v1/tts/live
Streaming Text Input (SDK)
For real-time applications where text arrives incrementally (e.g., from an LLM), the SDK supports streaming text input:
WebSocket vs SSE
Use WebSocket when sending multiple TTS requests over time (conversations, voice bots). Use SSE for simple one-shot streaming where you don’t need a persistent connection.
Response Format
The two transports emit different JSON shapes. Match your parser to the transport you’re using.
WebSocket (nested envelope):
- Read audio at
msg["data"]["audio"]. - Detect completion with
msg["status"] == "complete". There is nodonefield on WebSocket frames. session_idandrequest_idare informational metadata; safe to ignore for playback.
SSE (flat, one JSON object per data: line):
- Read audio at
msg["audio"]. - Detect completion with
msg["done"] == true.doneis present on every frame (falseon chunks,trueon the terminator), so"done" in msgmatches every frame. Compare the value. - SSE frames are prefixed with
event: audio\nfollowed bydata: {...}\n\n. statusmirrors HTTP-style codes (206for partial content,200on completion); informational.
Porting a WebSocket client to SSE? The two shapes are not interchangeable.
- WebSocket wraps every chunk in
{status, data.audio}; SSE returns{audio}at the top level. A parser written for the WebSocket envelope will silently drop every SSE frame becausemsg["data"]is undefined. - WebSocket signals completion with
status:"complete"and never emits adonefield. SSE signals it withdone:trueand also carriesdone:falseon every chunk.
Latency
TTFB is ~200 ms measured in-region, with inference pools in India (ap-south-1) and USA (us-west-2) geo-routed by client location. Client-to-server RTT adds on top. Measuring TTFB from a laptop far from either region typically reports 500-800 ms because RTT dominates synthesis. Test from the same network position where you’ll run production traffic. See the Lightning v3.1 model card for the full latency table.
Configuration Parameters
For concurrency limits and connection management, see Concurrency and Limits.
Full runnable source: streaming-python.py

