WebRTC Metrics
A comprehensive overview of WebRTC statistics, derived indicators, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats
jitterBufferDelay/jitterBufferEmittedCount(ms)
The average time, in milliseconds, each audio sample or a video frame waits in the jitter buffer.
Description
Real number; in milliseconds
This is the average jitter buffer delay: The calculation of the average time each audio sample or video frame waits in the jitter buffer before being taken out for playout.
This adds up to the latency observed by the user. We strive for this to be as close as possible to the average jitter on the network.
This metric is calculated by dividing the jitterBufferDelay with the jitterBufferEmittedCount.
Interpreting Values
Audio: | Range | Description | |-------|-------------| | <10ms | Unusually low. May mean insufficient buffering | | 20-80ms | Normal range | | 80-150ms | Elevated. Network jitter is high | | >150ms | Very high. Contributing significant end-to-end latency |
Video: | Range | Description | |-------|-------------| | 50-200ms | Normal range (typically higher than audio) | | >200ms | High. Adds noticeable latency |
Common Causes
High jitter buffer delay is caused by:
- High network jitter forcing a larger buffer
- Bursty packet loss
- Network transitions (e.g., WiFi handoff)
- VPN-induced jitter
User Experience Impact
- Every millisecond of jitter buffer delay adds to end-to-end latency
- 200ms of jitter buffer delay alone can make conversations feel sluggish
- Combined with RTT, total mouth-to-ear delay may exceed comfortable thresholds (generally 150-300ms before users notice)
Troubleshooting
- This is a symptom - fix the underlying jitter
- Check the jitter metric to confirm the network is actually jittery
- If jitter is normal but buffer delay is high, check jitterBufferMinimumDelay for application-set minimums
- Reducing network jitter (wired connection, QoS) is the real fix
See also
- inbound-rtp->jitter
- inbound-rtp->jitterBufferDelay
- inbound-rtp->jitterBufferEmittedCount
Notes
- An audio sample refers to having a sample in any channel of an audio track - if multiple audio channels are used, metrics based on samples do not increment at a higher rate, simultaneously having samples in multiple channels counts as a single sample
- We strive to have this delay as small as possible