Photo: JackApplegarth, CC BY-SA 4.0, via Wikimedia Commons

MIDI Latency Over WebRTC: What's Actually Achievable?

Introduction

Playing music together in the same room works because sound reaches everyone's ears within a few milliseconds. Do the same thing over the internet and that number can balloon to hundreds of milliseconds — enough that trying to keep a shared tempo turns into fighting an echo of yourself. Remote jamming has been a "someday" feature for a long time not because nobody wanted it, but because general-purpose internet infrastructure was never built around millisecond-level timing.

Where the latency actually comes from

"Internet latency" is really several stacked delays: the network round-trip time itself (bounded by physical distance and the speed of light through fiber, so geography sets a hard floor), jitter — the variation in that delay from packet to packet, which forces a receiving buffer to hold extra data just to smooth out inconsistency — and whatever encoding, decoding, and buffering happens at each endpoint before a note even leaves the sender's machine. Each layer adds a little; together they add up fast.

Why WebRTC is the right transport

Most web traffic goes through a server: client uploads, server processes, server sends back down. That extra hop is exactly what real-time collaboration can't afford. WebRTC is built differently — it's designed for direct peer-to-peer connections wherever the network allows, cutting out the round trip through a central server, and its data channels are built for exactly this kind of small, frequent, latency-sensitive message rather than large file transfer. That's why it's the natural transport for real-time MIDI, not just a convenient one.

Realistic numbers

Latency over WebRTC is fundamentally bounded by physical distance, and it shows: two musicians in the same city can often get round-trip latency low enough to feel genuinely playable together, while cross-continent connections usually land in "call and response" territory — good enough for trading ideas and layering parts, not for locking in a tight rhythm section in real time. That's not a limitation of any particular implementation; it's closer to a speed-of-light constraint that better code can shrink but not erase.

Design implications

A few practical consequences follow from all this. Sending MIDI events (a handful of bytes per note) rather than streaming audio keeps the payload tiny, which matters far more for latency than raw bandwidth ever does. Keeping messages small and frequent, rather than batching them, avoids adding artificial delay on top of the network's own. And because jitter hurts musical timing more than a slightly higher but consistent latency does, tuning for smooth, predictable delivery is often more valuable than chasing the lowest possible number.

Conclusion

Real-time MIDI over the internet isn't a solved problem in the sense of "latency goes to zero," but WebRTC gets closer than anything that routes through a server, and understanding where the delay actually comes from — distance, jitter, and endpoint processing — is what lets you design around it instead of being surprised by it.

Try it yourself with WebRTC MIDI, our browser-based collaborative MIDI router.