I'm evaluating PlayHT's streaming API for a potential integration, and I've hit a snag that smells like a vendor-side timeout issue masquerading as a network problem. On a stable but slower connection (simulated at ~3 Mbps), the WebSocket connection consistently drops at almost exactly the 120-second mark during a long text stream. The client-side error is a generic connection closure.
Before I get the inevitable "it's your infrastructure" response from support, I've ruled out the obvious:
* Local firewalls or proxies aren't interfering.
* The heartbeat/ping-pong is functional until the drop.
* The same code runs fine on a high-speed connection, and other streaming services (not TTS) maintain the connection on the same slow network.
This reeks of a hard-coded, server-side timeout that doesn't account for real-world variable network speeds, especially for a service that bills itself for "real-time" streaming. If the server is closing the connection because data isn't being consumed *fast enough* from its buffer, that's a design flaw. It's particularly problematic for longer-form content.
Has anyone else encountered this and found a workaround beyond chunking the text into sub-two-minute segments? I'm looking at the contract SLA for "availability" but this feels like a quality-of-service issue they've conveniently omitted.
The official documentation is silent on any keepalive requirements or timeout windows. Is this just another case of a SaaS vendor optimizing their infrastructure costs by dropping "problem" connections, while the client gets to shoulder the reliability blame?
Your mileage will vary
Classic. Their docs likely hide a caveat about "minimum throughput" in the SLA fine print. Check your contract for idle or data rate thresholds. It's not a bug, it's a feature you're not paying for.
Read the contract
Yep, that's the server-side idle timeout, standard for cheap API gateways. They likely have an ALB or Nginx config sitting in front of their actual service with a hard 2-minute keepalive.
>workaround beyond chunking the text
Chunking is the only real fix unless you want to implement client-side pings with dummy data to keep the socket busy, which is hacky. Their "real-time" probably assumes you're consuming the audio fast enough on a good connection to keep the buffer moving. On slow nets, your client can't drain it, so to them the connection looks dead.
You could try sending a null audio packet or a metadata ping every 90 seconds, but they might filter that out.
Keep it simple