Real-time factor (RTF)

Real-time factor is synthesis time divided by the duration of the audio produced: an RTF of 0.5 means four seconds of speech took two seconds to make. Below 1, synthesis outruns playback — the minimum bar for any streaming voice.

< 1

the bar any streaming voice must clear

What RTF tells you — and what it hides

RTF is a throughput number: it says the stream, once started, will not starve. It says nothing about when the stream starts. A system can post a flattering RTF and still take 800 ms to produce its first chunk, and the caller experiences the 800, not the ratio. For turn-taking, time to first audio is the governing figure; RTF only has to stay under 1.

Reading vendor numbers

An RTF quoted without load is an idle-box number — ask for it at your concurrency.
RTF measured on the model alone excludes the API path; the caller’s RTF includes it.
The pair that predicts a live call: first audio at p50/p95, plus sustained RTF under 1 at your line count. Ours: 107/108 ms single-stream first audio, and streams that do not starve at 16 concurrent callers.

Related sheets.

glossary

107 / 108

Time to first audio (TTFA)

TTFA is the delay from sending text to the first playable audio byte. How it differs from model latency and TTFB, and how to measure it honestly.

benchmark

813 ms

How the API behaves under load

What one GPU does under 16 concurrent callers — 430 ms median, 813 ms p95, zero failed requests — and how the API refuses traffic past absolute capacity.

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.

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

See the measured figures live