Jitter vs latency: which one actually breaks a video call

Jitter breaks video calls far more often than latency does. Latency is how long a packet takes to cross the network; jitter is how much that time changes from one packet to the next. A call app copes well with a steady delay: conversation feels a touch slower, and that is all. Jitter is harder, because the app must either wait for late packets, which adds delay, or give up on them, which sounds like loss. On Starlink, average latency is comfortably inside the call apps’ limits. The weak spot is short jitter spikes, mostly at satellite handovers, on top of whatever your home Wi-Fi and uploads add.

The two numbers in plain words

Latency is travel time. Apps and tools usually show the round trip: out to a server and back, in milliseconds. Our glossary has the short version.

Jitter is the wobble in that travel time. If one audio packet takes 30 ms, the next 32 ms and the next 31 ms, jitter is tiny. If they take 30, 75 and 35 ms, jitter is large even though the average looks fine. The standard for real-time media, RTP (RFC 3550), defines interarrival jitter as “the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender.” In short: how far packets drift from the even spacing they were sent with. See the jitter glossary entry for more.

Why calls tolerate steady delay

Human conversation has some slack in it. The ITU’s planning guide for voice networks, G.114, says that if one-way delay can be kept below 150 ms, “most applications, both speech and non-speech, will experience essentially transparent interactivity.” It also sets 400 ms as a limit not to exceed for general network planning.

Compare that with Starlink’s own report of a US median peak-hour latency of 25.7 ms (round trip, June 2025), or Ookla’s US median of 39 ms in Q1 2026. Even after adding the call server’s distance and the app’s own processing, a steady Starlink path leaves plenty of room. Latency on its own is rarely why a call on Starlink goes wrong.

Why jitter is harder

Audio is sent as a steady drumbeat of packets. To play it back smoothly, the receiving app needs packets to arrive on the same beat. When they don’t, it has a jitter buffer: a short waiting area that holds a few packets so it can release them evenly.

The buffer creates a trade-off with no free option:

• Small buffer: low delay, but any packet that arrives later than the buffer allows is treated as lost. You hear a clip or a robotic patch.
• Large buffer: smooth playback, but everything is delayed by the buffer’s length. Conversation gets that “walkie-talkie” feel and people start talking over each other.

Modern call apps adjust the buffer as conditions change. That works when jitter changes slowly. It struggles with sudden spikes, because the buffer is sized for the last few seconds, not for the spike that just arrived.

This is why loss and jitter often show up together in call statistics. A packet that arrives too late to play is, from your ear’s point of view, the same as a packet that never arrived. Our post on whether 1% packet loss is bad for calls explains how the app hides some of those gaps.

What jitter looks like on Starlink

APNIC’s Geoff Huston published a detailed look at Starlink’s behavior in 2024. Three findings matter for calls:

• A regular cycle. “The minimum latency changes regularly every 15 seconds,” which he links to the dish being assigned to a different satellite.
• Spikes at the switch. He saw “a major increase in latency at the point when the user is assigned to a different spacecraft,” with the worst case in his data “a shift from 30ms to 80ms.”
• Moderate jitter in between. Within each tracking interval, the average variation between successive round trips was 6.7 ms.

Read together: most of the time, Starlink jitter is small and well inside Microsoft’s 30 ms pass line. Every so often, a handover produces a jump of tens of milliseconds, sometimes with a lost packet or two. An adaptive jitter buffer handles many of those jumps. The ones it doesn’t handle are the brief stutters people describe. If you want to see how a typical figure can hide those bad moments, read p50 vs p95 latency.

Huston’s data isn’t from a US connection, and conditions change as the network grows. Treat the shape as the lesson, not the exact numbers.

Where your jitter is coming from

Not all jitter is the satellite’s. In many homes, most of it is added before the traffic reaches the dish.

How to check your own numbers

1. During a call: Zoom’s statistics panel and Teams’ call health show latency, jitter and loss for the current call. Note the time if they jump.
2. Outside a call: run a ping for five minutes (ping -n 300 1.1.1.1 on Windows, ping -c 300 1.1.1.1 on a Mac). Jitter isn’t printed directly, but you can see it: look at how much the times jump between lines. Big swings from line to line are jitter.
3. Compare: repeat on a cable, then with the VPN off, then with uploads paused. Change one thing at a time.
4. Match outages: compare the times of big jumps with the Starlink app’s statistics page. If it lists an outage at that moment, the dish side was involved.

A worked example: reading jitter from a ping log

Here is the kind of thing to look for. The times are illustrative, not a measurement from any one line:

reply time=31 ms
reply time=33 ms
reply time=30 ms
reply time=78 ms   <- jump of about 48 ms
reply time=36 ms
reply time=32 ms
Request timed out  <- a lost reply next to the jump
reply time=34 ms

The average of the replies is about 39 ms, comfortably under Microsoft’s latency line. A tool that only reports the average would call this line healthy. But the jump from 30 to 78 ms and back, with a lost reply nearby, is exactly the kind of moment a jitter buffer may not absorb. On a call, it could be a clipped word.

Now picture the same log where every line sits between 30 and 36 ms. The average is lower, but the bigger difference is that nothing jumps. That line would carry calls cleanly even if its average were 60 ms, because steady delay is easy for the app to plan around.

Two habits make your own logs more useful. Count the jumps of more than about 30 ms in five minutes. That isn’t the same calculation as an app’s jitter figure, but it is a simple, conservative way to spot the moments a call is most likely to struggle with. And note whether jumps repeat on a rhythm. A jump roughly every 15 seconds, with a cable in use and nothing uploading, fits the handover pattern Huston described. Jumps that cluster when someone starts a backup or a game download point to the home side instead.

Edge cases

• High latency but steady. A far VPN gateway can add a lot of latency without much jitter. Calls feel slow but sound clean. Ask IT whether a closer gateway exists.
• Low jitter but a frozen picture. If audio is fine and only video freezes, the app may be cutting video to protect audio during a busy upload.
• Jitter only at the same minute each hour. That pattern points to something scheduled, such as a backup job or a VPN timer. See VPN drops about once an hour.
• Jitter that is fine on tests but bad on calls. Short tests between calls may miss spikes that happen under load. Test while an upload is running to see the worst case.

Common mistakes

• Chasing latency. Steady latency under the app’s line is rarely the problem.
• Reading the average jitter only. Spikes are what break calls.
• Testing on Wi-Fi and blaming the dish. Always repeat on a cable first.
• Buying a faster plan to fix jitter. Extra download speed doesn’t steady packet timing.
• Turning on every “gaming” router feature at once. Change one setting, test, and keep a note.

What we don’t know

Call apps don’t publish exactly how their jitter buffers adapt, so nobody outside those companies can say precisely how much jitter a given call survives. Starlink doesn’t publish jitter figures by region or hour. The owner’s logger measures jitter to three targets every minute, and the Work-Day Reliability Report will show it by work hour once months are complete. The video calls guide covers the app settings that help on a line with occasional spikes.

What to do next

• Run the four checks above and fix the home causes first.
• If short handover stutters remain and your job is customer-facing calls all day, keep a dial-in number handy and consider a backup line; the Failover Builder sizes one.
• If loss shows up alongside the jitter, read Is 1% packet loss bad for calls? next.

Research-based: written from vendor documentation, Starlink support pages and standards, not from our own measurements. Starlink rules and prices on this page come from our dated fact file and show the day they were checked; they change, so confirm before you rely on one.Links to Starlink’s plan pages here use the site owner’s own referral link; the owner may get a referral reward and your price is the same. No affiliate links (how we make money). General information, not professional IT, legal or medical advice. Independent · not affiliated with SpaceX or Starlink. Spotted an error? Tell us.