Severe latency/regression with Chirp 3: HD long-audio

Google Cloud Build with AI AI APIs
1

We’re seeing a sudden and severe performance regression with Text-to-Speech “Chirp 3: HD” voices using the long-audio API. This worked reliably throughout August (8–12 min files completed in ~2–3 minutes). Since ~Sep 1, even short 1–2 min jobs take multiple minutes, and longer jobs (≥5–10 min) often never complete. Operations either remain QUEUED for extended periods or enter RUNNING and stall indefinitely at 20%.

Standard voices are unaffected and remain fast. Region is “us”, output bucket is regional (us-central1). We’re far below quotas, no code changes around Sep 1, and writes succeed when jobs finish. Logs show missing startTime/lastUpdateTime when jobs stall.

Has there been a change affecting Chirp 3: HD long-audio capacity or scheduling in “us” since Sep 1? Is there a known issue with progress stuck at 20%? Any recommended region/voice guidance to avoid this backlog?

Thanks,

2

Hey @cristian given long audio is still in Preview, ie. not production ready quite yet, can you try a different region and see if you get better performance?

3

Hi Andrew,

Thanks for your quick response! I have tried global, eu and asia-southeast1 yet still the same issue. I’m just not sure if it has been any change from Google’s side since the TTS jobs dramatically slowed down without any change on my code. Happens too with short audios (1 minute, maximum 2 minutes).

Appreciate your help, I’‘ll still investigate and try different things meanwhile.

Best,
Cristian

1 Like
4

I’m experiencing exactly the same issue since August 30th, and it’s still not working as of today. In my case, the region is europe-west1.

Jobs with Chirp 3: HD voices using the long-audio API remain either stuck in QUEUED or get to RUNNING and stall at 20%, even with relatively short files. Standard voices continue to work fine and complete quickly.

This happens across all generations, making the service essentially unusable at the moment. Could you confirm if there’s an ongoing capacity or scheduling issue affecting Chirp 3: HD long-audio across multiple regions?

Thanks,

5

Hola Carlos,

In my case it got fixed around 12th September. Suddenly and without changing anything on my code. So yeah, seems to be just how the API decides to give priority or not to long audio.