What's the actual latency for a 30-second generation via the API?

Your test batch average of ~8.5 seconds for a round trip is actually pretty close to what I've generally observed. For a clean 30-second script, I'd expect 7-12 seconds most of the time in production.

On your question about voice type and SSML complexity: yes, they absolutely can add variance. Some of the newer, more expressive voices do seem to take a bit longer to render. Heavy SSML, especially with complex pauses or pronunciation overrides, can also push you toward the higher end of that range. It's not usually a massive spike, but it's noticeable if you're benchmarking.

Since you're aiming for real-time feel, I'd definitely go with the progressive loading indicator. Even a 7-second wait needs some kind of feedback, and you'll get those occasional slower generations. The API response itself is quick; it's the file status polling that eats up the time.

That 7-12 second range sounds about right from my small-scale tests too. Your point about the progressive loader is good - even at the lower end, a few seconds of silence can feel weird to a user.

What voice did you end up using for your prototype? I'm curious if the simpler ones like 'Alex' really are faster, or if the difference is negligible for most use cases.

You're right to be skeptical of a small sample size. I ran a more rigorous test last quarter for a client doing 100,000+ generations monthly, and we found a bimodal distribution rather than a simple average.

The majority of 30-second clips with a standard voice like 'Alex' clustered between 5-9 seconds, which is promising. However, roughly 15% of requests fell into a slower band of 12-18 seconds, often correlating with internal platform load. Voice type and SSML complexity didn't create the primary variance, but they did consistently shift times within each band. 'Jenna' and other newer voices reliably added 1.5-2.5 seconds to whatever the baseline latency was.

So, your 8.5-second average isn't wrong, but it masks the long tail. For a real-time feel, you absolutely need that progressive indicator. Waiting on a synchronous call that could take nearly 20 seconds is a UX non-starter.

Bimodal distribution matches what I've seen in our logs. That slower band is crucial for capacity planning.

We also found regional API endpoints made a bigger difference than voice type for us. Routing to the closest one chopped a consistent 2-3 seconds off the long tail instances.

Planning for the 95th percentile, not the average, is the only way to make it feel responsive.

That's a great point about regional endpoints. We tested that last year and got similar results, shaving off a consistent 2 seconds from our p95 latency. It's often overlooked in the setup.

The 95th percentile planning is absolutely key. We built our loading states around that slower band, and it's saved us from feeling "slow" on those occasional long pulls. Have you found any other tricks that help smooth out the experience when you do hit that upper latency range?

That's a strong approach. Beyond the progressive loader, we've had success by analyzing the time to first byte of the final audio stream. We initiate a separate HEAD request to the provided URL as soon as the API responds, then monitor the status.

If that HEAD returns quickly, we know the audio is ready and can begin streaming for the user almost immediately. A delay there indicates the file is still processing, and we adjust our UI messaging accordingly from "generating" to "finalizing." It doesn't reduce the latency, but it provides a more truthful and less frustrating state to the user.

We've also seen that the streaming performance from Murf's CDN to the end-user is near-instantaneous and very stable, so once you get the file, playback isn't a concern.

That's a really clever idea, the separate HEAD request to check the actual file status. I love that it lets you refine the user message from a generic "generating" to a more accurate "finalizing." That kind of transparency probably cuts down on support tickets about perceived slowness too.

Do you find you need to set any special timeout or retry logic on that HEAD request, or does it usually just hang until the file is ready? I'm wondering if there's an edge case where it times out before the audio is actually done.

Love the idea of a simple test batch. You're on the right track.

For setting expectations, I'd plan for that 12-18 second long tail user777 mentioned, even though most come back faster. I've seen the same bimodal split in our cost reports when we mapped instance spin-up times to the billing second increments. A progressive loader is cheap UX insurance.

Haven't seen SDK choice make a meaningful difference, but +1 to checking your regional endpoint. That's an easy win. If your Node client is deployed in us-east-1 but hitting a default EU endpoint, you're adding network hops for no reason.

Your initial average of ~8.5 seconds is a solid starting point, but as others have noted, it's the distribution that matters. For planning a real-time feel, focusing on the central tendency is a mistake.

Based on my own controlled tests (n=1500 generations, split evenly between 'Alex' and 'Jenna' with standardized scripts), the p95 latency was 16.2 seconds, not the 12-18 second band mentioned. The long tail is fatter than it seems. Voice type was a statistically significant factor (p I'm trying to decide if I need to implement a progressive loading indicator

You absolutely do. The cognitive threshold for "seamless" is under 2 seconds for audio feedback. Anything above that requires a clear, staged status. I'd model your loader states on the HEAD request method user883 described, but also trigger a fallback static message at a hard timeout of 20 seconds to manage abandonment.