Bug Report: TTS Audio Cuts Off After ~1 Second and Restarts (Remote UI Access)

Date: 2026-05-20 09:36 PDT
Reporter: Rick (via Jetty)
OpenClaw Version: 2026.5.18
Severity: High - Voice replies unusable

---

Summary

When accessing the Control UI/WebChat from a different PC than the gateway server, TTS audio replies cut off after approximately 1 second and then restart/loop. The audio clearly begins playing (confirming TTS is hooked up and working), but something interrupts the stream mid-playback.

---

Environment

Gateway Server:

• Host: aiserver01 (Linux 6.8.0-117-generic x64)
• OpenClaw: 2026.5.18
• Gateway bind: 127.0.0.1:18789 (loopback only)
• Node: v22.22.2
• Default model: ollama/qwen3.5:397b-cloud

Client/UI:

• Access method: Control UI/WebChat on separate PC (not the gateway host)
• Network: Remote access to gateway (likely via Tailscale or reverse proxy — needs confirmation)
• Browser: Unknown (needs confirmation)

Talk/TTS Config:

• No explicit talk.* configuration in openclaw.json
• No explicit messages.tts.* configuration found
• Likely using browser TTS or default gateway TTS path

---

Symptoms

1. Audio starts playing — User can hear the beginning of the reply (confirms TTS generation is working)
2. Cuts off after ~1 second — Audio stream interrupts mid-sentence
3. Restarts/loops — Audio begins again from the start (or continues from a buffer restart)
4. Repeats — Cycle continues, making voice replies unusable

---

Expected Behavior

TTS audio should play through to completion without interruption, regardless of whether the UI is accessed locally or remotely.

---

Actual Behavior

Audio stream is interrupted after ~1 second and restarts, creating a looped/cut-off playback experience.

---

Hypothesized Root Causes

1. Network streaming interruption — Audio chunks not arriving fast enough over remote connection; buffer underrun causes restart
2. CORS/connection issue — Remote PC accessing gateway audio stream hits CORS or connection reset
3. Audio chunking bug — Gateway or UI mishandles chunked audio responses when not on localhost
4. WebSocket timeout — Audio streaming WebSocket closes prematurely on remote connections
5. Bandwidth/latency — Remote connection can't sustain audio stream bitrate

---

Reproduction Steps

1. Run OpenClaw gateway on server (aiserver01)
2. Access Control UI/WebChat from different PC (not localhost)
3. Enable voice/TTS replies (Talk mode or TTS setting)
4. Send a message that triggers a spoken reply
5. Observe audio cuts off after ~1 second and restarts

---

Workarounds

• Use UI on same machine as gateway — Localhost access may avoid the streaming issue
• Disable TTS/voice replies — Use text-only mode until fixed
• Check network path — If using Tailscale/reverse proxy, test direct connection

---

Diagnostic Info Needed

• Client PC OS and browser (Chrome/Firefox/Safari/Edge?)
• How is remote PC accessing gateway? (Tailscale, reverse proxy, port forward?)
• Browser console errors when audio cuts out (Network tab, Console tab)
• Gateway logs during audio playback (/tmp/openclaw/openclaw-2026-05-20.log)
• Network latency/bandwidth between client and gateway
• Does this happen with short replies (<5 sec) or only longer ones?
• Does text-only mode work fine? (confirm it's audio-specific)

---

Related Issues

• #75155 — Talk Mode: user voice transcripts don't render in WebChat/Control UI thread
• #67465 — Control UI/WebChat: configured Talk mode has no visible UI surface
• #45508 — Self-hosted STT/TTS provider support in webchat (Route webchat TTS through gateway instead of browser Speech API)
• #47311 — Server-side STT option for webchat voice input

---

Suggested Fix Direction

1. Investigate audio streaming path — Trace how TTS audio is delivered to remote UI clients
2. Add buffering/retry logic — Handle network hiccups without restarting playback
3. Check WebSocket/audio stream timeouts — Ensure remote connections aren't being closed prematurely
4. Add diagnostic logging — Log audio stream start/stop/errors to help debug
5. Test with explicit TTS provider config — Verify if this is browser TTS vs gateway TTS specific

---

Priority

High — Voice replies are a core Talk mode feature. This bug makes the feature unusable for remote UI access, which is a common deployment pattern (gateway on server, UI on laptop/desktop).

---

Filed by Jetty 🐈‍⬛