Text to Speech API for Developers: Evaluation Guide

A text to speech API for developers turns text into audio over HTTP or WebSocket, but choosing one is harder than the marketing pages suggest.

Published latency figures measure different things, language counts include voices you would not ship, and commercial rights vary by plan. The right evaluation compares streaming behavior, concurrency limits, expressivity, licensing, and pricing units on your own text, in your own region.

This guide explains why vendor speed claims are not comparable, how to set a latency target that reflects what your application actually does, which criteria change the outcome once a voice runs in production, and how to run a short benchmark that produces numbers you can defend to your team.

Why Published TTS Latency Numbers Are Not Comparable

Vendors publish at least five different numbers and call all of them latency. Each one excludes something the next one includes, so ranking providers by their published figures compares measurement definitions rather than performance.

The five most common are model inference time, time to first audio (TTFA), time to first byte (TTFB), audio synthesis time for a complete file, end-to-end request time including network transit, and full conversational round-trip time across an entire voice pipeline. TTFA and TTFB are often used interchangeably, but they are not identical: a first byte is not always a decoded, playable chunk. A provider can be fastest on one metric and mid-pack on another.

ElevenLabs' models page lists eleven_flash_v2_5 at approximately 75 ms, then adds that the figure excludes application and network latency. Its latency guidance then reports real time to first byte of 100 to 150 ms in North America, Europe, and Southeast Asia, and 150 to 200 ms in South Asia and Northeast Asia, using Flash models over WebSockets. Both numbers are accurate. The second one better approximates when the API starts responding, though it still excludes client buffering, decoding, and playback.

Deepgram's text to speech latency documentation models total latency as network plus TTFB plus audio synthesis, and offers a baseline estimate of roughly 600 ms of constant latency plus 40 ms per 100 characters. The two worked examples measured 756 ms total for a 300 character request and 879 ms total for a 900 character request over cURL, against estimates of 720 ms and 960 ms, without streaming optimizations enabled. Deepgram reports stable sub-200 ms p95 TTFB, reaching around 90 ms under steady-state conditions on its Enterprise Runtime. Both figures describe the same Aura-2 model family and differ by more than 8x, because one is total request time over a hosted cURL call and the other is first-byte latency on specified GPUs under steady load.

Time to First Audio and End-to-End Latency Are Not Interchangeable

Time to first audio is the interval between sending a request and receiving the first playable audio chunk. End-to-end latency is the interval between the trigger event and the moment the listener hears speech, which includes network transit, connection setup, buffering, and playback.

TTFA is the number that determines whether a conversation feels responsive, because playback can begin before synthesis finishes. End-to-end latency is the number that determines whether your service level objective holds, because it includes everything TTFA leaves out. Substituting one for the other is the most common error in TTS evaluation, and published comparisons repeat it.

Roundups routinely place a first-byte figure from one vendor in the same column as a complete-file generation time from another, producing rankings that differ by orders of magnitude depending on which definition the author used. Before you compare any two providers, confirm that both figures measure the same event.

What Latency Target Actually Matters for Your Application

Set the target from the interaction, not from the leaderboard. Real-time conversation, streamed narration, and batch rendering have different budgets, and only the first one is genuinely latency-critical.

For conversational agents, human turn-taking research provides the anchor. Work summarized in Timing in Conversation (Meyer, Journal of Cognition, 2023) reports that the modal gap between turns in everyday conversation is around 200 ms, with median latencies in conversational corpora usually under 300 ms, and cites Stivers and colleagues finding median gap durations between 0 and 300 ms across ten languages. These figures provide a human conversational reference point rather than a proven latency requirement for voice agents, and they describe a whole exchange rather than the TTS call alone. Human speakers also begin planning their reply while the other person is still talking, which a cascaded pipeline does not do.

The i-LAVA analysis of low-latency voice-to-voice architecture (Choudhary and Purwar) decomposes a GPU pipeline into automatic speech recognition (ASR) at 0.5056 seconds, large language model (LLM) generation at 2.1502 seconds, and TTS at 0.6695 seconds, and concludes that LLM response generation remained the bottleneck in that architecture. One experimental pipeline does not generalize to every stack, but it shows that shaving 30 ms off TTFA may have little perceptible impact when the pipeline is losing two seconds upstream.

Decide the total response time you need, subtract measured ASR and LLM time, and treat the remainder as your TTS allowance. If that remainder is 400 ms, a provider at 90 ms and a provider at 200 ms may both fit, in which case voice quality, languages, and licensing should decide. Confirm that with application-level testing rather than assuming it from the component figures.

For long-form narration, audiobook rendering, and localization work, TTFA matters much less. Throughput, prosody stability across thousands of words, and consistency between separately generated segments determine the result, though TTFA still affects preview and interactive editing workflows where an operator waits on each render.

The Criteria That Separate TTS APIs in Production

Once latency is scoped correctly, five criteria account for most of the difference between a demo that sounds good and a deployment that holds up.

Streaming Architecture and Protocol

Streaming support is not binary. Providers differ on whether they stream output only, or also accept streamed input, and that difference changes your integration. Output streaming sends audio chunks as they are generated. Input streaming accepts text incrementally, which matters when you are piping tokens from an LLM and do not want to wait for a complete sentence.

ElevenLabs documents three modes: a standard endpoint returning complete audio, a server-sent events streaming endpoint, and a WebSocket endpoint for bidirectional streaming with real-time text input. Cartesia documents three TTS endpoints: a bytes endpoint and a server-sent events endpoint that both stream output, and a WebSocket endpoint that is the only one accepting streamed text input or multiple generations on one connection. OpenAI's speech guide supports real-time streaming through chunked transfer encoding.

Check the output format list at the same time. Telephony deployments need 8 kHz G.711, which is mu-law on North American and Japanese networks and A-law across most of Europe, and a provider that only returns MP3 forces a transcode step into your hot path. Cartesia documents both, listing pcm_mulaw and pcm_alaw alongside pcm_f32le and pcm_s16le across sample rates from 8000 to 48000 Hz. OpenAI recommends WAV or PCM for the fastest response times because compressed formats add encoding time.

Concurrency and Behavior Under Load

Concurrency limits are often the constraint that ends an evaluation, and they are frequently buried in pricing rather than documentation. Cartesia publishes concurrent request caps per plan: 2 on Free, 3 on Pro, 5 on Startup, 15 on Scale, and custom on Enterprise. Read those numbers against the workload, not as a call count. Cartesia states that conversational traffic supports roughly 4x the TTS concurrency limit, since agents are silent for much of a call, so a limit of 15 typically covers about 60 parallel conversations. A contact center still needs to confirm that ratio against its own talk-time profile.

Deepgram's own scaling write-up frames the problem in terms of stream density per GPU, reporting a 30 to 40 percent improvement over the previous generation while stating that the benchmarks are not absolutes. Ask every shortlisted vendor for p95 and p99 TTFA at your target concurrency, in your deployment region, and treat a refusal to provide it as a data point.

Expressivity and Long-Form Stability

Expressivity is measurable but not with a single scalar. Preference scores, ELO ratings, and mean opinion scores each capture something different, and most are collected on short clips that do not predict behavior across a ten minute passage.

Long-form stability is the property that separates the two use cases. A model can produce an excellent 8 second sample and still drift in pitch, pace, or character across a long call or a full episode. If your workload involves extended sessions, test with input at production length rather than the sample text in the quickstart.

Controls matter more than raw quality scores for agent work, because they determine whether you can correct a bad read without regenerating everything. Look for explicit parameters covering accent, tempo, pitch, emotional intensity, and a seed value for reproducibility. Accent handling in particular is a separate capability from voice selection: it controls whether a voice can take on a locale-appropriate accent, or hold one accent consistently across languages, independent of which language is being spoken.

Voice Licensing and Commercial Rights

Licensing is the criterion that comparison roundups skip most often, and the one most likely to stop a deployment at legal review. Three questions decide it: does the plan you are on include commercial use, does the provider hold documented consent from the voice talent behind each voice, and can you show that chain of rights to a customer or regulator.

ElevenLabs, for example, includes a commercial license from its paid Starter tier rather than on the free plan, which is easy to miss during a prototype.

For any voice cloning work, obtain documented authorization covering the intended use, territory, and term. A publicly available recording does not by itself establish commercial permission, and consent for one project does not extend to another. If your product clones customer or talent voices, the provider's consent workflow and retention policy belong in your evaluation alongside latency, and its published data ethics and IP handling commitments are a reasonable place to start.

Pricing Units and Cost Predictability

Providers price in characters, credits, or minutes, and the unit determines how predictable your bill is. Character pricing is the easiest to forecast because you can compute cost directly from your text volume: as of this writing, Deepgram lists Aura-2 at $0.030 per 1,000 characters pay-as-you-go and $0.027 per 1,000 characters on Growth on its published pricing page. Vendor pricing changes without notice, so confirm current rates directly before building a cost model on any figure cited here, Deepdub's included.

Credit systems introduce a conversion layer, and the conversion rate can differ by model and by feature, which makes forecasting harder. Cartesia's plans bundle credits with estimated minute equivalents, and additional features such as voice changer are billed separately per second of audio. Model your cost on realistic traffic, including retries and regenerations, not on the headline rate.

How Current Text-to-Speech APIs Compare

The figures below come from what each vendor documents publicly. Every speed figure is labeled with what it measures, because the figures are not equivalent to each other.

Deepdub's Phantom Z 3.4 Conversational (eTTS™) posts roughly 85ms typical time-to-first-audio, with a 150ms p95 figure end-to-end in real-time mode, across more than 50 languages and locales, with accent control independently extending across 130+ languages. It streams over both REST and WebSocket.

ElevenLabs' eleven_flash_v2_5 posts approximately 75 ms model inference only, explicitly excluding application and network latency, with 100 to 200 ms time-to-first-byte by region over WebSockets. It supports 32 languages on Flash v2.5 and 29 on Multilingual v2, streaming over SSE and WebSocket.

Cartesia's Sonic 3.5 posts a first byte of audio in 90 ms, with methodology not published, across 42 languages, streaming over bytes, SSE, and WebSocket endpoints.

Deepgram's Aura-2 (the company now recommends Flux TTS for English) posts roughly 600 ms constant latency plus 40 ms per 100 characters without streaming per its documentation, and sub-200 ms p95 TTFB, around 90 ms in steady state, per its engineering blog, across 7 languages, streaming over REST and WebSocket.

OpenAI's gpt-4o-mini-tts publishes no latency figure. It accepts 99+ input languages, with voices optimized for English, streaming through chunked transfer encoding.

Use these figures to shortlist on languages and streaming model, then generate your own latency numbers.

How Developers Should Benchmark a Text to Speech API

An initial benchmark can be built in about a day and produces numbers that survive review. Run the same protocol against every shortlisted provider, and hold the variables that vendors leave unstated constant across all of them.

Use your own text: pull 50 representative utterances from real transcripts, not marketing copy, and include the awkward ones with numbers, product names, and code-switching. Fix the measurement point by recording the timestamp when the request is sent and the timestamp when the first audio byte arrives, and report that as TTFA, with completion recorded separately.

Test from your deployment region, running the client in the same cloud region your service will run in rather than from a laptop, and report percentiles rather than averages: publish p50 and p95 across at least 500 requests per provider. A good average with a long tail produces bad calls, and a p99 drawn from a few hundred requests rests on two or three observations, so treat it as indicative until you have run more.

Repeat under concurrency, rerunning at your expected peak concurrent streams and again at 2x, since providers diverge here more than at a single stream. Test long-form separately by generating at least one full-length passage per provider and listening for drift in pitch, pace, and character.

Hold format constant, requesting the same encoding and sample rate from every provider, since compressed formats add encoding time. Log failures: timeouts, truncated audio, and rate-limit responses belong in the results table alongside latency.

Publish the protocol with the results. A benchmark whose method is written down can be rerun when a provider ships a new model version, and model versions change often enough that undated numbers are close to worthless.

Where Deepdub Fits

Deepdub is relevant to this evaluation when expressivity and long-form stability matter as much as speed, and when licensed voices are a procurement requirement rather than a preference.

Deepdub's Voice API for Agents exposes emotive Text-to-Speech (eTTS™) through REST and WebSocket endpoints, with controls for accent, tempo, pitch, emotional intensity, seed, and variance, and Python and Node.js SDKs documented at docs.deepdub.ai.

On expressivity, Deepdub's own English eTTS benchmark, a blind study conducted by Deepdub rather than an independent third party, reports Phantom X 3.2 at an ELO of 1545, a statistical tie for first place with Inworld TTS 1.5-max at 1549, and ahead of Hume Octave at 1498, Async Flash v1.0 at 1493, and ElevenLabs Turbo v2.5 at 1416, with TTFA of roughly 125 ms measured under what the page describes as identical conditions.

The licensing point is the one most likely to matter at review. Deepdub's voice bank is built from licensed voices, and the Voice Artist Royalty Program compensates artists each time their voice is selected for a project while artists retain their rights. If your product ships synthetic voices to customers in a regulated industry, that chain of consent is easier to evidence than a voice of uncertain provenance.

Frequently Asked Questions

What is the difference between TTFA and end-to-end latency? Time to first audio measures the interval between sending a request and receiving the first playable audio chunk, so playback can begin before synthesis completes. End-to-end latency measures everything the listener experiences, including network transit, connection setup, buffering, and playback. TTFA determines whether a conversation feels responsive. End-to-end latency determines whether your service level objective holds.

How fast does a voice agent actually need to respond? Research on conversational timing reports a modal gap of roughly 200 ms between turns, with median gaps usually under 300 ms. That budget covers the entire pipeline, not the TTS call alone. Since speech recognition and language model generation typically consume most of it, calculate your TTS allowance by subtracting measured upstream time rather than targeting the lowest published figure.

Does a higher language count mean better multilingual quality? No. A multilingual TTS system converts text into speech across many languages and dialects, but coverage is not uniform. Language counts often include languages where voice quality, prosody, or accent handling are noticeably weaker than in English. OpenAI, for example, supports input in 99 or more languages while documenting that its voices are optimized for English. Test each language you intend to ship with native speakers.

Do I need commercial rights to use synthetic voices in a product? Yes, and the rights depend on your plan and the provider's own licensing chain. Several providers grant commercial use only on paid tiers. For voice cloning, obtain documented authorization from the voice owner covering the intended use, territory, and term, since a publicly available recording does not by itself establish commercial permission. Confirm both your license and the provider's consent documentation before launch.

Should I use one TTS API for both voice agents and long-form content? Often not. Agent workloads optimize for time to first audio, streamed input, and concurrency. Long-form and media audio work optimizes for prosody stability, consistency across segments, and throughput. Some providers serve both well, but verify by testing production-length input for the long-form case rather than assuming that short-clip quality scales.