Live Dealer Chips Land 60ms Before the Video Does

If you've played live blackjack on a decent connection, you've probably felt it without naming it: the chip sound arrives, then the card flips, then the dealer's hand moves. On a 40ms ping to a European server, the audio cue can land roughly 60ms ahead of the matching video frame. That gap is small enough to ignore and large enough to notice, and it's baked into how live dealer streams are built.

The stream is slower than the game state

Live dealer software doesn't wait for the video. The game engine processes your bet, the dealer's action, and the card draw on the server, then pushes a state update over a WebSocket or similar channel. The video is a separate pipeline: camera capture, hardware or software encode, packaging into HLS or WebRTC segments, CDN distribution, and finally your player's buffer.

That video path adds latency at every hop. HLS typically runs 6–10 seconds behind real time. WebRTC-based live dealer feeds have pushed that down to 400–800ms on a good connection, which is why most operators switched. But even WebRTC carries encode and jitter-buffer delay that the game state channel doesn't.

So the state update — including the audio trigger for chip placement — often wins the race by tens of milliseconds.

Why 60ms specifically

It's not a fixed number. On a 20ms connection with a well-tuned WebRTC feed, the gap can shrink to 15–25ms. On a 120ms mobile connection with a congested buffer, it can stretch past 150ms. The 60ms figure shows up repeatedly in player reports and latency testing on European-facing tables, which is where most of the volume sits. It's a median, not a law.

What actually causes the desync

Three things, roughly in order of impact:

Audio and video are decoded on different clocks. The game state channel fires the chip sound the moment the server registers the bet. The video decoder is still working through its buffer. If the player holds 200ms of video buffer to avoid stutter, the audio has a 200ms head start before you even account for encode delay.

Buffering is asymmetric. Players tolerate audio glitches less than video glitches, so many clients run a smaller audio buffer. That's a deliberate trade-off, and it widens the gap.

CDN edge routing varies. Your state update might hit a server 30ms away. Your video might route through an edge node 80ms away. The difference stacks.

Does it matter for outcomes?

No. The cards are already determined server-side before the video shows them. Seeing the chip land early doesn't give you information about the next card — the RNG or the shuffle happened upstream. This is a perception problem, not an integrity problem.

But perception matters. A 60ms audio lead makes the game feel slightly "off" in a way players can't articulate. Some operators have started delaying the audio cue to match the video, which fixes the feel but adds a different kind of lag: now the sound arrives after you've already seen the chip move.

There's no clean fix. You can sync to the slower channel and make everything feel sluggish, or sync to the faster one and accept the gap. Most operators pick the second option and hope nobody notices.

The question nobody's answering

If WebRTC latency keeps dropping — and it will — the video will eventually catch the state channel. At that point the gap closes, and the desync disappears. But the same infrastructure that closes it also makes the game feel instant, which changes how players perceive the dealer. A dealer who reacts in real time feels less like a person and more like a rendered avatar.

So the real question isn't whether operators can fix the 60ms gap. It's whether they should. The slight delay is doing quiet work: it makes the stream feel live in a way a perfectly synced feed might not.