# Synthetic agent audio drops out in browser despite intact source and zero reported packet loss **URL:** \ **Category:** Agents\ **Tags:** agent-sdk-node-js\ **Created:** [September 29, 2026, 6:03am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136 "2026-09-29T06:03:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Anna\_Hahn](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/anna_hahn/32/2518_2.png) [@Anna\_Hahn](https://community.livekit.io/u/Anna_Hahn)\ **Post date:** [September 29, 2026, 6:03am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/1 "2026-09-29T06:03:08Z")
We run a LiveKit Cloud voice agent with a Railway-hosted publisher and a Chromium browser receiver. Users hear clipped syllables. To isolate delivery from the LLM and TTS, we sent a deterministic synthetic tone through the agent audio path and recorded the decoded browser output. The source was intact, but one run had 5.36 seconds of near-silence at the browser. The next run with the same source did not reproduce it. The browser remained visible with its AudioContext running and there was no deliberate interruption. Its capture callback gap was only 16.1 ms. Receiver stats increased by about 270,000 concealed samples (about 248,000 silent), with zero reported lost packets and about 80,000 samples removed for acceleration. The sender’s JS event-loop delay peaked below 18 ms. We used `@livekit/agents` 1.6.4 with a 2,000 ms output queue, livekit-client 2.22.3, and Chrome 153. A matched comparison with 1.9.0 did not establish an SDK fix. We did not independently record physical speaker output. What sender RTP, SFU, receiver-arrival, and playout measurements would distinguish publisher timing, SFU forwarding, and receiver jitter-buffer behavior in this situation? Is there a supported way to capture a packet-level timeline for a fresh synthetic run without retaining conversation content? We can provide the room ID, exact UTC interval, and synthetic source/receiver recordings privately to LiveKit staff. Separately, a full-WAV LiveKit byte-stream pilot completed three transfers in 1.8–2.7 seconds, then one exceeded a 30-second deadline. We did not isolate the blocked stage and do not assume it shares the RTP failure’s cause. Are there supported send/write/close diagnostics for byte streams? ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [September 29, 2026, 1:04pm UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/2 "2026-09-29T13:04:04Z")
> [@Anna\_Hahn](#): > > Users hear clipped syllables ^ That is the fundamental issue you are trying to resolve, correct? It looks like your analysis has focused on the underlying transport, but I don’t know if that is the right approach. My top suspicions would be: - Firewall issues, [Configuring firewalls | LiveKit Documentation](https://docs.livekit.io/deploy/admin/firewall/). If your synthetic tests **are** showing drop out, this is the most likely cause. - Noise cancellation configuration, [LiveKit noise cancellation: what it is and how it works | LiveKit](https://livekit.com/blog/noise-cancellation) . Perhaps the audio is being clipped due to overly aggressive noise cancellation. - CPU / Memory limits on your self-hosted agent server, [Self-hosted deployments | LiveKit Documentation](https://docs.livekit.io/deploy/custom/deployments/#memory-and-cpu). I also suggest checking your agent logs for clues. [Where to find your Agent Logs | LiveKit](https://livekit.com/blog/agent-logs) Can you share a session ID or two for the original issue, starting `RM_`, and share the session as described [here](https://docs.livekit.io/testing/observability/insights/#share-session-link), I can take a look. ---
**Author:** ![Anna\_Hahn](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/anna_hahn/32/2518_2.png) [@Anna\_Hahn](https://community.livekit.io/u/Anna_Hahn)\ **Post date:** [September 30, 2026, 4:17am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/3 "2026-09-30T04:17:38Z")
Yes—the clipped syllables are the issue we need to resolve. Today’s controlled Chrome 154 test used an intact 71-second Cartesia source. Fine alignment of decoded browser PCM still shows about 60 ms of near-silence at source 9.64–9.70 s and about 40 ms of severe attenuation at 66.025–66.065 s. Receiver concealment increments correlate with these defects; capture cadence stayed continuous (maximum gap under 43 ms). The agent nevertheless reported the response delivered. Most coarse screening flags disappeared under finer alignment, so we are reporting only these remaining internal defects. This isolated output test has no microphone input or noise-cancellation processing. Our earlier fixed-tone test also bypasses TTS. We will check firewall and host resource evidence as suggested; we have not independently localized the publisher/SFU boundary. Versions remain agents 1.6.4, rtc-node 0.13.34, client 2.22.3. Separately, today’s full-WAV byte-stream soak completed 22 verified continuous speech plays before transfer 23 failed during browser receive. Last progress was 524,288 of 1,090,900 bytes (not necessarily exact consumed bytes). Sender write/close completed, followed by repeated “Cannot enqueue a chunk into a closed readable stream” browser errors. A local SDK reproduction shows that this burst can follow an original missing-chunk rejection. We added original-error and consumed-byte diagnostics; a fresh long-source transfer also failed with paced writes. This may relate to [Uncompressed data streams silently accept missing and out-of-order chunks · Issue #2072 · livekit/client-sdk-js · GitHub](https://github.com/livekit/client-sdk-js/issues/2072) and [fix: error on uncompressed datastreams when chunks are missing by lukasIO · Pull Request #2073 · livekit/client-sdk-js · GitHub](https://github.com/livekit/client-sdk-js/pull/2073), but we have not established the same root cause. These deterministic fixture tests use a directly connected RTC publisher. We are also running the real dispatched production worker with an owned synthetic account. Is the room ID plus exact UTC interval sufficient for the packet/SFU investigation, or do you need an Insights agent-session share link? Please indicate the appropriate private channel for synthetic room IDs and source/receiver evidence. We will keep user conversations and recordings out of this report. ---
**Author:** ![abidullahcs.uk](https://avatars.discourse-cdn.com/v4/letter/a/ba8739/32.png) [@abidullahcs.uk](https://community.livekit.io/u/abidullahcs.uk)\ **Post date:** [September 30, 2026, 7:04am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/4 "2026-09-30T07:04:26Z")
@Anna_Hahn One thing worth correcting: you already have #2073. It shipped in livekit-client 2.22.2 as “fix: error on datastreams when chunks are missing”, and you’re on 2.22.3. So it isn’t a candidate root cause, it’s what’s surfacing yours. Before that fix, missing chunks were accepted silently. Now the stream rejects and closes, and your “Cannot enqueue a chunk into a closed readable stream” burst is simply the writes arriving after that close. That matches your own observation that the burst follows an original missing-chunk rejection. Which leaves the real question as why a chunk goes missing at all, which is closer to #2072 than to the fix for it. One concrete lead: 524,288 is exactly 512 KiB. A transfer stalling on a round power of two points at a buffer boundary rather than a random drop. Worth checking whether the failures always land on that same number, or whether it moves between runs. The RTP and SFU side needs packet-level visibility, so that half stays with @darryncampbell . ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [September 30, 2026, 7:36am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/5 "2026-09-30T07:36:04Z")
> [@Anna\_Hahn](#): > > Please indicate the appropriate private channel for synthetic room IDs and source/receiver evidence. We will keep user conversations and recordings out of this report. If you just give me the start / end time of the room (in UTC) I can find it that way. For the agent tests, I also notice you have Observability disabled on your project; it would really help if you enabled this and shared the session, since it provides a lot of helpful information. Personally, I would still recommend keeping an open mind what the root cause might be, rather than assuming a low level transport issue ---
**Author:** ![Anna\_Hahn](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/anna_hahn/32/2518_2.png) [@Anna\_Hahn](https://community.livekit.io/u/Anna_Hahn)\ **Post date:** [September 30, 2026, 9:30am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/6 "2026-09-30T09:30:15Z")
Thank you. The latest failing synthetic RTP test ran on 2026-09-30 from 03:39:36.385 UTC to approximately 03:41:15.764 UTC, including setup and teardown. This is the run described above: intact 71-second Cartesia source, Chrome 154, agents 1.6.4 / rtc-node 0.13.34 / client 2.22.3, with approximately 60 ms of near-silence and 40 ms of attenuation in decoded browser audio. This output-only test had no microphone or noise-cancellation input processing. Can you locate that room and inspect it using this window? Agreed on #2073: the missing-chunk rejection is already present in our installed client. It detects an incomplete transfer; it does not explain why chunks are absent. The earlier 524,288-byte figure was sampled progress, not exact consumed bytes. A fresh long-source transfer subsequently failed after 604,824 consumed bytes with missing chunks 73..189, so the observed boundary is not consistently 512 KiB. We are keeping publisher scheduling, host resources, networking and receiver behavior open as possible causes. We have retained the paired synthetic evidence. For Insights, could you clarify whether content-free diagnostics or recording limited to an explicitly synthetic session can be shared while project-wide conversation recording remains disabled? We need to avoid retaining private user conversations. ---
**Author:** ![Liam\_Johnson](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/liam_johnson/32/2663_2.png) [@Liam\_Johnson](https://community.livekit.io/u/Liam_Johnson)\ **Post date:** [September 30, 2026, 10:54am UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/7 "2026-09-30T10:54:22Z")
This post was flagged by the community and is temporarily hidden. ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [September 30, 2026, 1:20pm UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/8 "2026-09-30T13:20:04Z")
I don’t see any network issues in our server logs during that test. Your publisher is in the USA and your subscriber is in Indonesia so there will be latency due to geography but that shouldn’t cause any clipped audio. The next step would be to run a more realistic test, with a dispatched agent and Observability enabled, that would better help identify what is causing the clipped audio. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\ **Post date:** [October 15, 2026, 1:20pm UTC](https://community.livekit.io/t/synthetic-agent-audio-drops-out-in-browser-despite-intact-source-and-zero-reported-packet-loss/2136/9 "2026-10-15T13:20:30Z")
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.