Suddenly been facing issue. It works intermittently. When I see logs, I see there is generation of LLM, TTS and STT but no audio is heard by the user and there is nothing in the egress recording either. I’m on

# LiveKit core
livekit==1.1.2
livekit-agents==1.4.5
livekit-api==1.1.0
livekit-protocol==1.1.1

Thanks for reaching out, Abhishek. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

It was working fine last week and suddenly started happening since yesterday. No new release. Did something change in livekit cloud recently that can cause this issue?

Thanks — I understand this started suddenly and you want to know if LiveKit Cloud changed recently and could cause the silence. I don’t have any record of a cloud-side change that would intentionally remove audio for LLM/TTS/STT flows. To help pinpoint whether this is cloud-side or a local pipeline issue, please share the following so I can narrow it down quickly: 1. Confirmation whether TTS is injected server-side via LiveKit Agents (published as a participant/track) or published from a client. 2. A short, timestamped log snippet showing: ◦ the LLM → TTS generation completion ◦ the publish/track attach actions to LiveKit ◦ any track/egress warnings/errors immediately after 1. The TTS output format and sample rate (e.g., 16 kHz PCM, 48 kHz Opus). 2. Which clients/platforms hear silence (all clients or only specific ones like web/iOS/Android). 3. Whether you see RTP/track stats (nonzero packets/bytes) for the published track during silent segments. While you gather that, please run these quick checks: • Play the TTS file locally on the server to confirm it contains audio. • Inspect LiveKit track stats at the silent timestamps to confirm packets/bytes and codec info. • Check egress logs for codec conversion or dropped-track warnings at the same times. Once you paste the log snippet and the format/platform info, I’ll give specific diagnostics and next steps (including exact fields in logs to look for and how to verify codec/packet continuity). , with interactive elements

Here are the logs 2026-05-12T124830.250+05:30 {“message”: “LLM metrics”, “level”: “INFO”, “name”: “livekit.agents”, “model_name”: “gpt-5.3-chat-latest”, “model_provider”: “api.openai.com”, “ttft”: 0.68, “prompt_tokens”: 4160, “prompt_cached_tokens”: 3840, “completion_tokens”: 5, “tokens_per_second”: 6.98, “pid”: 55507, “job_id”: “AJ_FvHHdwXYdpLA”, “room_id”: “RM_YxuV4MrCnSZv”, “timestamp”: “2026-05-12T071830.250434+00:00"} 2026-05-12T124830.463+05:30 { “message”: “TTS metrics”, “level”: “INFO”, “name”: “livekit.agents”, “model_name”: “chirp_3", “model_provider”: “Google Cloud Platform”, “ttfb”: 0.12068383098812774, “audio_duration”: 1.04, “pid”: 55507, “job_id”: “AJ_FvHHdwXYdpLA”, “room_id”: “RM_YxuV4MrCnSZv”, “timestamp”: “2026-05-12T071830.462959+00:00” } {“message”: “TTS metrics”, “level”: “INFO”, “name”: “livekit.agents”, “model_name”: “chirp_3”, “model_provider”: “Google Cloud Platform”, “ttfb”: 0.12068383098812774, “audio_duration”: 1.04, “pid”: 55507, “job_id”: “AJ_FvHHdwXYdpLA”, “room_id”: “RM_YxuV4MrCnSZv”, “timestamp”: “2026-05-12T071830.462959+00:00"} 2026-05-12T124831.858+05:30 {“message”: “STT metrics”, “level”: “INFO”, “name”: “livekit.agents”, “model_name”: “u3-rt-pro”, “model_provider”: “AssemblyAI”, “audio_duration”: 6.5, “pid”: 55385, “job_id”: “AJ_FxWhC5pSE46u”, “room_id”: “RM_gnwevsKigw8e”, “timestamp”: “2026-05-12T071831.856992+00:00"} 2026-05-12T124831.858+05:30 {“message”: “EOU metrics”, “level”: “INFO”, “name”: “livekit.agents”, “model_name”: “unknown”, “model_provider”: “stt”, “end_of_utterance_delay”: 0.48, “transcription_delay”: 0.47, “pid”: 55385, “job_id”: “AJ_FxWhC5pSE46u”, “room_id”: “RM_gnwevsKigw8e”, “timestamp”: “2026-05-12T071831.857537+00:00”} 2026-05-12T124832.649+05:30

Thanks — I’m sorry you hit this suddenly. I checked the logs you pasted: LLM, TTS, and STT metrics look healthy and there are only INFO entries, so TTS generation succeeded but audio never reaches listeners or egress. I don’t see any record of a LiveKit Cloud change that would intentionally remove audio. To narrow this down quickly, please confirm two things: • Is TTS injected server-side by a LiveKit Agent (agent publishes a participant/track) or published by a client? • Does the silence affect all participants and egress, or only some client platforms (web/iOS/Android)? Immediate targeted checks to run now: 1. Play the TTS output file on the server to confirm it contains audible audio. 2. Enable DEBUG logs for the agent and reproduce the issue; share the DEBUG log lines around the same timestamps (we need to see publish/track frames and any publish errors). 3. Check LiveKit track stats at the silent timestamps for the agent’s track: confirm packets/bytes > 0 and codec name (Opus vs PCM). 4. On a client, verify you receive

trackSubscribed

and that playback isn’t muted/volume=0 and the track’s

enabled

flag is true. 5. Inspect egress job config/logs to ensure the agent’s participant/track is included in the recording mix and check for any codec-conversion warnings. What to paste here that will let me pinpoint the fault: • DEBUG log snippet showing the TTS publish attempt and any track-related events (timestamps). • The TTS audio format and sample rate (e.g., 16kHz PCM, 48kHz Opus). • One set of track stats for the room at the failure time (packets/bytes, codec). • Which client platforms are affected. If you share those, I’ll give exact next steps (specific log fields to inspect and fixes for the common causes: track not published, codec mismatch, client subscription/playback issues, or egress misconfiguration). Sources: Why is my Agent insights data missing? | LiveKit | Server startup modes | LiveKit Documentation | Job lifecycle | LiveKit Documentation, with interactive elements

Started working again without any change.

Thanks — I know how frustrating intermittent audio bugs are. I’ll help narrow this down quickly. First, two short confirmations: • Is TTS injected server-side by a LiveKit Agent (agent publishes a participant/track) or published from a client? • Does the silence affect all participants and egress, or only some platforms (web/iOS/Android)? Please capture and paste the following when it next fails (these are the things that will let me pinpoint the cause): • DEBUG-level agent log snippet around the failure timestamps (including publish/track attach events). • The TTS audio format and sample rate (e.g., 16 kHz PCM or 48 kHz Opus). • LiveKit track stats for the agent’s track at the failure time (packets, bytes, codec). • A client console log showing receipt of

trackSubscribed

(or lack thereof) and whether playback is muted/volume=0. • Egress job/log lines near that time showing which participants/tracks were recorded. While you reproduce, run these quick checks: 1. Play the TTS file locally on the agent host to confirm it contains audio. 2. Confirm the agent publish succeeded (no publish errors) and that track stats show packets/bytes > 0. 3. Verify codec negotiation: published codec matches what clients/egress expect (codec mismatch can produce silence). 4. Ensure the client actually subscribed and the track’s `enabled`/volume aren’t disabled. 5. Check egress configuration includes the agent participant/track and watch for codec conversion warnings. If you paste the DEBUG logs, track stats, and the format/platform info, I’ll provide exact fields to inspect and the most likely fixes (track publishing bug, codec mismatch, subscription/playback issue, or egress exclusion). , with interactive elements

• published by livekit agent • Yes all participant affected. If I say something that is also not recorded in egress recording

Thanks — I know intermittent silence like this is painful. From what you’ve shared: TTS is generated successfully by the agent (your logs show healthy LLM/TTS/STT INFO entries), and the silence affects all participants and egress. There’s no indication of a LiveKit Cloud change that would intentionally cause this. Likely cause • The agent’s audio track is not being successfully published (or is being muted/interrupted) even though TTS generation completes. Egress only records published tracks, so missing published audio explains silent recordings. Immediate steps to collect the minimum diagnostics I need 1. Enable DEBUG logs for the agent and reproduce the failure. Paste the DEBUG log lines around the failure timestamp that include publish/track events. 2. Capture LiveKit track stats for the agent’s audio track at the failure time (packets, bytes, codec name). 3. Confirm the TTS audio file is audible by playing it on the agent host. 4. Confirm the agent isn’t muted or being interrupted (

session.interrupt()

or explicit mute calls). 5. Share your egress job config/log lines for the same time to confirm the agent participant/track is included. Quick checks you can run now • Verify the TTS file locally plays (if it’s silent locally, the problem is upstream). • Confirm

publishTrack

succeeded (no publish errors) and track stats show packets/bytes > 0 during the silent window. • Verify codec negotiation: the published codec (e.g., Opus) matches what clients/egress accept. • On a client, check you receive

trackSubscribed

events and that playback isn’t muted/volume=0. Optional: version note • There are fixes in agent publishing behavior in newer agent releases. If you can, consider testing with a newer

livekit-agents

build in a staging room and compare behavior. If it fails again, please paste: • DEBUG log snippet with publish/track events (timestamps), • the agent track stats (packets, bytes, codec), • the TTS file sample rate/format, and I’ll pinpoint the exact field to inspect and the likely fix. Sources: Job lifecycle | LiveKit Documentation | Why is my Agent insights data missing? | LiveKit | Diagnosing Connection Errors with Connection Test Utility | Agent speech and audio | LiveKit Documentation, with interactive elements

Do i need use openai chat completion or responses api here?

Thanks — quick answer: use the OpenAI Responses API. Why: • For direct OpenAI usage with LiveKit Agents, use

openai.responses.LLM()

(Responses API). It gives better performance, access to newer features, and lower cost. • The Chat Completions API (

openai.LLM()

) is for OpenAI-compatible endpoints or legacy setups. If you want, I can: • Show a small example of switching to

openai.responses.LLM()

in your agent code, or • Help confirm your current integration is using the Responses API and not falling back to the Chat Completions flow. Which would you prefer? Sources: OpenAI LLM models | LiveKit Documentation | Why is my Agent insights data missing? | LiveKit | Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit, with interactive elements