Thanks — I’m glad you asked. I’ll address common causes of jitter on a LiveKit local deployment and what you can check or change to reduce it. What I’m responding to: you said your local LiveKit deployment shows lots of jitter. Below are the most common reasons for that behavior and practical checks/actions to try. Network-related causes (most common) • Variable latency or congestion between clients and the server causes packet timing to vary. Check RTT and packet loss from client → server. • Firewalls/NAT can allow initial UDP but block later packets, or force fallback to TCP/TLS/TURN which increases latency. Confirm UDP connectivity and TURN setup for restrictive networks. • Suboptimal routing or the server being far from participants increases RTT and makes NACK repairs slower — colocate the server nearer your users if possible. What to check • Run ping/traceroute between clients and the server to measure RTT and jitter. • Capture packet loss and latency over time (e.g., mtr, iperf, or browser WebRTC stats). • Confirm ICE candidates show a direct UDP path; if not, verify TURN config and connectivity. Resource and host configuration • Insufficient CPU, memory, or network I/O on the machine hosting LiveKit causes packet delays/drops. Media forwarding (SFU) is CPU+bandwidth intensive. • If you’re running many participants or high-res streams, ensure the host has enough outbound bandwidth and CPU headroom. What to check • Monitor host CPU, memory, NIC usage, and transmit queues during sessions. • Reduce resolution/framerate temporarily to see if jitter improves. AV sync and publishing issues • Large audio/video buffering or pushing audio and video frames sequentially in the same task can introduce delays and drift. • An oversized AV synchronizer queue increases latency. What to check / change • Use smaller AV synchronizer queue sizes (for example, reduce to ~200 ms where applicable). • Push audio and video frames from separate asynchronous tasks so one stream doesn’t block the other. Transport fallback and connection stability • If UDP briefly fails and the client falls back to TCP/TLS or TURN, latency can spike and cause jitter. Ensure transport fallback is working cleanly. • TURN relays add latency; confirm TURN servers are reachable and close to clients if needed. What to check • Inspect WebRTC stats in the browser (or client) to see ICE transport changes and whether traffic is relayed through TURN. • If TURN is used, test a TURN server near your users. Quick troubleshooting checklist (start here) 1. Collect WebRTC stats during a problematic session (RTT, packetLoss, jitter, transport type). 2. Measure host resource usage (CPU, NIC bandwidth) while reproducing the issue. 3. Confirm UDP connectivity and ICE candidate types; test TURN if UDP blocked. 4. Try lower bitrate / resolution to see if quality stabilizes. 5. If possible, run a client colocated with the server to confirm whether the problem is network vs. host. If you’d like, I can help interpret specific diagnostics — for example: • The client’s getStats output (key RTCInbound/RTCOutbound transport metrics). • Host CPU/memory and NIC usage during a session. • ICE candidate logs or a sample publishing code snippet. Which of those diagnostics can you share first (getStats, host metrics, or ICE logs)? I’ll walk you through the exact next steps based on what you can provide. Sources: How we built a globally distributed mesh network to scale WebRTC | LiveKit | Bringing Zoom's end-to-end optimizations to WebRTC | LiveKit | Firewall Tips | Yeah, but can it run DOOM? | LiveKit | Debugging Audio/Video Sync Issues in LiveKit Publishing, with interactive elements