Streaming TTS

tl;dr: All Rime models stream.

Rime’s TTS API streams audio as it is generated rather than waiting for the full utterance. Coda and Mist v3 stream over HTTP and WebSockets. Under typical conditions, the cloud API delivers sub-200ms end-to-end latency. For real-time voice agents, streaming is the default mode of operation.

Choosing a transport

	HTTP streaming	Coda WebSocket v1	Legacy WebSocket JSON (`/ws3`)
Endpoint	`POST https://coda.api.rime.ai/` or `https://mist.api.rime.ai/`	`wss://coda.api.rime.ai/ws`	`wss://users-ws.rime.ai/ws3`
Models	All	Coda	Coda and Mist v3
Connection	One request per utterance	Persistent, multi-utterance	Persistent, multi-utterance
Input	Full text upfront	Incremental text (e.g. from a streaming LLM)	Incremental text
Word-level timestamps	❌	✅	✅
Interruption handling	Close the connection	`cancel` + context IDs	`clear` operation + context IDs
Best for	Simple integrations, server-side synthesis	New Coda voice agents, conversational AI, telephony	Existing integrations and Mist v3 streaming

Rules of thumb:

Building a voice agent on Coda? Use Coda WebSocket v1. A persistent connection avoids per-utterance handshakes, you can feed text in as your LLM generates it, and context cancellation lets you stop synthesis when a caller interrupts. Coda WebSocket v1 also returns word timestamps when you ask for them.
Synthesizing complete sentences server-side? HTTP streaming is the simplest path: one POST, audio bytes stream back in the response body.
Already using LiveKit, Pipecat, Vapi, or Daily? The integrations handle transport for you. Rime plugs in as the TTS stage of the pipeline.

HTTP streaming

A single POST to the model’s host, such as https://coda.api.rime.ai/, returns audio bytes in the response body as they are generated. The Accept header controls the format: Opus, MP3, WAV, PCM, or G.711 μ-law. See the full format table.

cURL

curl --request POST \
  --url https://coda.api.rime.ai/ \
  --header 'Accept: audio/mpeg' \
  --header "Authorization: Bearer $RIME_API_KEY" \
  --header 'Content-Type: application/json' \
  --output output.mp3 \
  --fail \
  --show-error \
  --data '{
  "text": "Streaming audio from Rime, as it is generated.",
  "speaker": "astra",
  "lang": "en"
}'

Python

import os, requests

with requests.post(
    "https://coda.api.rime.ai/",
    headers={
        "Authorization": f"Bearer {os.environ['RIME_API_KEY']}",
        "Content-Type": "application/json",
        "Accept": "audio/mpeg",
    },
    json={
        "text": "Streaming audio from Rime, as it is generated.",
        "speaker": "astra",
        "lang": "en",
    },
    stream=True,
) as response:
    response.raise_for_status()
    for chunk in response.iter_content(chunk_size=4096):
        ...  # feed chunk to your player, telephony stream, or file

The first audio bytes arrive long before synthesis finishes. Consume the body incrementally (as above) rather than buffering the whole response, or you give back most of the latency win. See Latency for measured time-to-first-audio per model. Endpoint references: Coda · Mist v3

Keep whole samples in raw PCM

Chunks follow the network, not the audio. With raw PCM (audio/L16), a chunk can end in the middle of a 16-bit sample. If your player plays that chunk as it is, every later sample shifts by one byte, and the rest of the audio plays as static. So keep the odd byte, and put it in front of the next chunk:

leftover = b""
for chunk in response.iter_content(chunk_size=4096):
    data = leftover + chunk
    whole = len(data) - len(data) % 2  # Whole 16-bit samples only
    play(data[:whole])  # Your player
    leftover = data[whole:]

let leftover = Buffer.alloc(0);
for await (const chunk of response.body) {
  const data = Buffer.concat([leftover, chunk]);
  const whole = data.length - (data.length % 2); // Whole 16-bit samples only
  play(data.subarray(0, whole)); // Your player
  leftover = data.subarray(whole);
}

In Python, response is the streaming response from the example above. In Node.js, it is the result of fetch. The WebSocket APIs do not promise whole samples in each message either, so do the same with raw PCM from a WebSocket. Formats that you feed to one decoder, such as MP3, Opus, and WAV, need no extra step. G.711 μ-law has one byte per sample, so its samples never split.

WebSocket streaming

Use Coda WebSocket v1 when text arrives over time or you need to cancel individual turns. To send LLM tokens as they arrive, set splitStrategy to SPLIT_STRATEGY_ACCUMULATE_SENTENCE, and the server joins them into sentences. Without it, send complete sentences, because the server normalizes each message separately. The connection stays open between turns. See the Coda WebSocket v1 reference for the lifecycle and message fields. Use the JSON quickstart or the Protobuf quickstart for runnable clients. The LiveKit integration covers both encodings. For Mist v3, use the same protocol at wss://mist.api.rime.ai/ws. The Mist v3 WebSocket reference covers what differs from Coda. Existing integrations on the legacy /ws3 endpoint keep working. Its protocol uses different operations, such as flush, clear, and eos, and the legacy Coda and Mist v3 /ws3 references still describe it. See Segmentation & behavior settings.

Streaming for telephony and IVR

For phone-based voice agents and IVR systems, request audio that matches the telephony codec directly. Rime synthesizes G.711 μ-law (audio/PCMU) and 8kHz-sampled audio natively, so no transcoding step sits between synthesis and the caller:

Set Accept: audio/PCMU (HTTP) or audioParameters.audioFormat: "audio/pcmu" in a Coda WebSocket v1 start for μ-law output. On the legacy /ws3 endpoint, set audioFormat=mulaw in the query string.
Set samplingRate: 8000 to match the telephony stream and shrink payloads. On Coda WebSocket v1, set it inside audioParameters.

Telephony and voice-agent platform guides: LiveKit · Vapi · SignalWire · Daily · VideoSDK

Latency

Listeners experience time to first audio, not total synthesis time, so streaming has the largest effect on perceived responsiveness. Under typical conditions, Rime’s cloud API delivers sub-200ms end-to-end latency. With mistv3, typical time to first byte is well below 100ms. Coda achieves sub-100ms model latency on the GPU engine when self-hosted or on-prem.

Latency

Measured benchmarks per model, what affects response time, and how to reduce it; regional endpoints, payload sizing, and text normalization.

Get started

Build with Rime

Integrations

Account & updates

tl;dr: All Rime models stream.

Choosing a transport

HTTP streaming

Keep whole samples in raw PCM

WebSocket streaming

Streaming for telephony and IVR

Latency

Latency

​tl;dr: All Rime models stream.

​Choosing a transport

​HTTP streaming

​Keep whole samples in raw PCM

​WebSocket streaming

​Streaming for telephony and IVR

​Latency

Latency

tl;dr: All Rime models stream.

Choosing a transport

HTTP streaming

Keep whole samples in raw PCM

WebSocket streaming

Streaming for telephony and IVR

Latency