https://livekit.io logo
Join Slack
Powered by
our platform has a way for users to use webrtc or ...
# ask-ai
i
our platform has a way for users to use webrtc or livekit and when we switch them over to livekit, some users report more audio and videos freezing or being delay, why does this happen?
t
Thanks for reaching out, Noah. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I understand you’re seeing more audio/video freezing or delays for some users after switching them from your existing WebRTC implementation to LiveKit. I’ll explain the common causes and give practical next steps you can try and questions to help narrow the root cause. Why this can happen (common causes) • Adaptive behavior during network congestion: LiveKit will reduce or pause video to preserve audio and overall session stability when bandwidth is limited. That behavior can look like freezing video or delayed updates if the client UI doesn’t indicate the pause. • SFU stream allocation: Because LiveKit uses an SFU, it dynamically chooses which tracks to forward based on available bandwidth and track priority (audio first, then screen share, then video). If many tracks are subscribed, lower-priority video may be reduced or paused. • Buffer / AV sync settings: Larger audio/video buffers (for example a high 
queue_size_ms
) increase latency; smaller buffers reduce delay but risk more underruns. Default or mismatched buffer sizes between your old client and LiveKit can change perceived delay. • Asynchronous event handling: LiveKit sends stream-state updates asynchronously (e.g., 
trackStreamStateChanged
and 
stream_state_update
), so clients that expect immediate state changes may show “frozen” frames until the event is handled. • DTX / Opus behavior: Opus DTX (discontinuous transmission) reduces audio bitrate during silence. In some setups this can affect perceived sync or audio gaps if the client does not handle DTX as expected. • Client-side conflicts or SDK integration differences: Platform-specific issues (for example certain background plugins on mobile) can interrupt the media pipeline and cause freezes that weren’t present in your prior WebRTC setup. Practical troubleshooting steps (start here) 1. Confirm network conditions for affected users: ◦ Check upstream/downstream bandwidth, packet loss, and RTT during the reported freezes. ◦ See if freezes correlate with poor networks or specific ISPs/regions. 1. Observe LiveKit stream state events: ◦ Ensure your client listens for 
trackStreamStateChanged
/ 
stream_state_update
and surface a UI indicator (e.g., “video paused due to bandwidth”) so users understand it’s adaptive behavior. 1. Review track/subscription counts and priorities: ◦ Test sessions with different numbers of participants/tracks to see when the SFU starts reducing video quality. ◦ Try temporarily lowering subscribed video quality or unsubscribing noncritical tracks. 1. Tune buffering/synchronization: ◦ If you’re using or exposing 
queue_size_ms
or similar buffer settings, try reducing it toward ~200ms to reduce delay (don’t go too low if networks are lossy). ◦ Verify audio/video sync logic on the client. 1. Reproduce on controlled devices/networks: ◦ Run tests on a stable LAN and on constrained networks (throttled) to compare behavior between the old WebRTC flow and LiveKit. ◦ If only reproducible on particular OS/browser versions, focus on those builds. 1. Check client SDK and plugins: ◦ Verify you’re on the recommended LiveKit client SDK version for each platform. ◦ Look for platform plugins that might pause media (background tasks, battery savers, audio route handlers). Targeted questions to narrow scope • Do the freezes happen for all users or only certain clients (mobile vs desktop, specific OS versions, specific browsers)? • Do freezes correlate with poor network metrics (high packet loss, high RTT, low bandwidth)? • How many participants/tracks are typically in sessions where users report problems? • Are you already listening for stream-state events in the client and surfacing them to users? • Have you compared buffer/synchronization settings (e.g., 
queue_size_ms
) between your previous WebRTC implementation and your LiveKit client? What I can help with next • If you share which client platforms and SDK versions are affected, I can suggest platform-specific checks and code snippets to log stream-state events. • If you can share typical session scale (participants and tracks) and an example of network stats during the issues, I can help map likely SFU or congestion behaviors and recommend specific settings to change. If you prefer, start by answering a couple of the targeted questions above (platforms affected and whether you see 
stream_state_update
events). I’ll then give focused steps or code examples to test and resolve the freezes. Sources: Managing Video Quality During Network Congestion | LiveKit | Debugging audio/video sync issues in LiveKit publishing | LiveKit | Handling asynchronous metadata updates in LiveKit | LiveKit | Managing Video Quality During Network Congestion | Bringing Zoom's end-to-end optimizations to WebRTC
i
are there any settings i can modify to help users with freezing?
t
Thanks — I’m responding to your question about specific LiveKit settings you can modify to reduce audio/video freezing. Below are concrete settings and practical actions (client- and server-side) you can try, plus which ones to prioritize first. Client-side settings and changes • Listen for and surface stream-state events ◦ Ensure your client listens for 
trackStreamStateChanged
/ 
stream_state_update
and shows a UI indicator when LiveKit pauses a video for bandwidth reasons. This prevents users from thinking the feed is broken. • Adjust audio/video buffer / AV sync ◦ Reduce 
queue_size_ms
(or equivalent buffer size) toward ~200ms to lower delay. Larger values (e.g., >1000ms) increase latency and make freezes feel longer. • Control subscription preferences ◦ Prefer subscribing at lower resolutions or frame rates when network conditions are poor (e.g., 360p or 15fps). Let clients request higher quality when their metrics are good. • Implement adaptive quality selection ◦ Detect network conditions (bandwidth, packet loss, RTT) and switch profiles automatically: lower bitrate or resolution when metrics degrade, raise when stable. • Ensure codec and DTX handling is appropriate ◦ If you observe odd audio gaps, verify your client handles Opus DTX properly. If necessary for a specific use case, test disabling DTX to compare behavior. • Verify SDK and platform integrations ◦ Confirm you’re on recommended LiveKit client SDK versions and check for interfering plugins (background services, battery savers) that could pause media pipelines on mobile. Server-side / SFU-related settings and practices • Reduce published track encodings ◦ Publish fewer simulcast layers or limit maximum simulcast layers so the SFU has fewer streams to manage. This reduces CPU/bandwidth pressure and the chance the SFU will pause lower-priority streams. • Prioritize tracks ◦ Ensure audio tracks are highest priority (default), and set screen-share or important video as higher priority than less important camera feeds where supported. • Limit total subscribed tracks per participant ◦ If users routinely subscribe to many video tracks, limit simultaneous subscriptions or implement “active speaker” style subscription to reduce bandwidth usage. • Monitor and tune SFU allocator behavior ◦ Observe when the SFU pauses video due to congestion. If you see frequent allocator-driven pauses, reduce session density (fewer simultaneous videos) or increase server capacity. Network and operational tuning • Improve network conditions where possible ◦ Encourage use of wired/Ethernet connections for critical sessions; ensure Wi‑Fi environments aren’t congested. • Use TURN in constrained networks ◦ Make sure TURN servers are configured and reachable so clients behind strict NATs can maintain stable connectivity. • Collect diagnostics from affected clients ◦ Log bandwidth estimates, packet loss, RTT, and any stream-state events to identify patterns. Priority checklist (what to try first) 1. Confirm clients are listening for 
trackStreamStateChanged
/ 
stream_state_update
and show the user a clear message when video is paused for bandwidth. 2. Reduce 
queue_size_ms
toward ~200ms on clients to lower perceived delay. 3. Lower video resolution/frame rate or reduce simulcast layers for affected users. 4. Ensure TURN is available and test on both wired and wireless networks for reproducibility. 5. If problems persist on specific platforms, verify SDK version and check for conflicting plugins. If you’d like, tell me: • Which client platforms/SDK versions are affected (web, iOS, Android, Flutter, etc.) • Typical session size (participants and how many simultaneous video tracks) • One sample set of client diagnostics (bandwidth estimate, packet loss, RTT) during a freeze With that info I can give platform-specific configuration examples or a short troubleshooting plan you can run.
2 Views
Open in Slack
PreviousNext
Powered by