Gemini 2.5 Pro TTS Inconsistent Accent and Pacing

Gemini 2.5 Pro Text-to-Speech launched with impressive capabilities: 30 voices, more than 80 locales, and natural-language style control that lets you steer emotion and delivery with a sentence instead of a dozen prosody knobs. It has already become one of the most interesting production Text-to-Speech options of 2026 - the quality ceiling is high, the pricing is competitive with ElevenLabs on large-scale runs, and the expressive range on Pro is genuinely excellent for podcasts and audiobooks.

The floor is a different story. Real production users are hitting real problems: audio that truncates mid-sentence with no error in the response, voices that swap identity inside a multi-speaker dialogue, hallucinated lines that were never in the input, metallic ringing introduced by a December 2025 model update, and accent or pacing drift between otherwise identical calls. Google's own AI Developer Forum has threads with dozens of reproducible bugs - one production user documented seven distinct failure modes in a single week - but there is no independent resource that aggregates them into a practical quality guide.

This post covers every documented Gemini Text-to-Speech quality issue we have seen in production, which of the Gemini Text-to-Speech models is most affected by each, and how to detect the failures automatically before your users do.

The Gemini Text-to-Speech model landscape. Google currently ships three related but distinct Text-to-Speech products under the Gemini and Cloud umbrella, and the failure modes differ between them. Gemini 2.5 Flash Text-to-Speech is the low-latency tier - faster responses, slightly less expressive, targeted at interactive and real-time use cases like voice agents. Gemini 2.5 Pro Text-to-Speech is the quality tier, designed for podcasts, audiobooks, and long-form narration, with richer prosody and multi-speaker dialogue support. Chirp 3 HD, Google's older neural line, still sits alongside the Gemini stack and is the only one that accepts SSML input and supports voice cloning. Knowing which of the three you are calling matters because the same prompt can produce different artifacts on each - and the quality workarounds differ accordingly.

Documented quality issues. The six failure modes below are the ones we have seen Gemini Text-to-Speech users hit most often, drawn from Google's developer forum threads, our own batch audits, and reports from teams running Gemini in production. None of them are theoretical - every one has been reproduced on the current model builds as of April 2026.

1. Truncation and finishReason "OTHER". The audio cuts off mid-sentence with no error signal - the API returns a 200, the finishReason field comes back as "OTHER", and the downstream consumer never notices until a listener hits the cliff. This is documented across gemini-2.5-flash-tts, gemini-2.5-pro-tts, and the newer gemini-3.1-pro-preview build, so it is not isolated to a single version. There is no server-side fix today. The workaround is client-side: treat finishReason "OTHER" as an error, compare the expected duration of the script against the duration of the returned audio, and retry on mismatch. Expect to do this on roughly one in a hundred long-form calls.

2. Voice swapping in multi-speaker mode. In Gemini 2.5 Pro's multi-speaker dialogue mode, the voice assigned to Speaker A can suddenly switch to the Speaker B timbre partway through a conversation, or the other way around. The swap is usually subtle enough to survive a cursory listen but obvious enough for an audience to notice and flag. Podcast and audio-drama teams hit this the hardest. There is no parameter today that reliably locks each speaker to a single voice across a long multi-turn dialogue.

3. Hallucinated lines and inserted words. The model occasionally inserts words - or entire sentences - that do not exist in the input text. We have seen it add filler phrases at paragraph boundaries, repeat the last line of a previous chunk, and on one occasion invent a sentence that summarised what the speaker was about to say. This is the same class of failure documented in Coqui XTTS and early ElevenLabs v3 runs, and the only reliable detection method is to transcribe the output with Whisper and diff against the source script.

4. Metallic noise after the December 2025 update. The model update Google shipped in December 2025 introduced an audible metallic artifact - thin, ringing, and especially noticeable on sustained vowels and sibilants. Users simultaneously reported that expressivity and prompt adherence had degraded, and the community coined the phrase "TTS model nerfed December" for the regression. Google eventually acknowledged the change. Parts of it have been partially rolled back since, but the metallic ringing still appears intermittently on Pro.

5. Voice inconsistency between clips. Call the model twice with the same voice ID, the same text, and the same settings, and the second clip can come back sounding like a different narrator - different accent, different pacing, or a subtly different timbre. In real batch workflows, around 1 in 10 outputs can hit this kind of drift. It is the same voice drift problem covered in our accent leakage post, applied to Gemini specifically. There is still no seed parameter on any of the Gemini Text-to-Speech models, so you cannot pin a preferred take. The only fix is to audit each batch and regenerate the outliers.

6. Latency and streaming gaps. When you stream Gemini Text-to-Speech output in real time, there is a noticeable delay between segments - a short silence, sometimes tens of milliseconds, sometimes hundreds, that makes continuous playback feel less smooth than the equivalent streaming path on ElevenLabs. For voice agents and interactive use cases this is the single most common complaint, and it is a Gemini-side issue rather than a client-side buffering one.

How these issues compare to other platforms. Every modern Text-to-Speech platform fails some of the time. The useful question is which failure modes you are likely to hit first, and whether you can catch them before your users do. The table below summarises where Gemini sits relative to ElevenLabs, Azure, and a representative open-source model like Coqui XTTS on the six issues above.

The point is not that one platform is best and another is worst - every platform has its own failure profile. The teams who ship polished audio are the ones who run an automatic check against that profile on every batch, regardless of which provider generated the file. See our companion guides on ElevenLabs v3 quality issues and OpenAI TTS-1 production reliability for how the same class of failures shows up on other providers.

Detecting Gemini Text-to-Speech quality issues at scale. Manual listening stops scaling somewhere around fifty files. TTSAudit batch-processes your Gemini Text-to-Speech output and surfaces the observable symptoms of the failure modes above: voice drift between files (Speaker Consistency check), metallic artifacts and other quality anomalies (Audio Quality check), pacing drift (Speaking Speed check), and — if you pass the original script — missing, hallucinated, or repeated lines plus spoken stage directions (Script Accuracy check). Upload a batch via the REST API and get a per-file report with scores and labels. Regenerate only the clips that failed instead of regenerating the whole batch. Most teams catch one or two broken files in every hundred - the difference is that now they catch them before a listener does.

You can audit your Gemini Text-to-Speech output with TTSAudit using 100 free credits on signup, no credit card required.