Multiroom audio latency: why your zones fall out of sync and how to fix it

Forty milliseconds. That's roughly the point at which your brain starts registering audio delay as an echo rather than a room effect. I've sat in open-plan living areas where the kitchen Sonos speaker was playing the same song as the lounge system, and the gap between them was painful — not subtle, not something you'd explain away with room acoustics. Just plainly, audibly wrong. And when I pulled up a delay analyser on my phone, sure enough: the two zones were drifting by 60–80 ms, sometimes more as the track ran on.

Multiroom synchronisation is one of those engineering problems that looks solved on a spec sheet and is genuinely hard in practice. Every major ecosystem — Sonos, Apple AirPlay 2, Google Cast, WiiM, BluOS, HEOS — makes claims about tight sync, and most of them are at least partially true under ideal conditions. The trouble is that ideal conditions are rare, and the ways each system handles real-world network variability are quite different. Understanding the mechanism tells you a lot about which system will behave well in your house specifically.

What multiroom latency actually is

People conflate two separate problems, and it's worth separating them. The first is absolute latency: the delay between a source sending audio and a speaker playing it. A single zone with 2 seconds of buffered latency sounds perfectly fine because you never notice the delay in isolation. The second problem is relative latency: the timing difference between two zones playing simultaneously. This is the one that matters, and the one that's hard.

Every wireless audio transmission has to contend with Wi-Fi's fundamentally non-deterministic behaviour. Packets don't arrive in perfectly regular intervals. Access points have queuing, retransmission, and contention overhead that varies second to second depending on how many devices are active, which channel they're on, and whether the neighbour's router is hammering the same spectrum. Each endpoint receiver buffers incoming packets to smooth this jitter out, which is smart — but each endpoint does it independently, and if the buffer sizes or refill timing drift slightly, zones drift apart.

The engineering solution is coordinated playback with timestamped scheduling. Instead of each device playing audio as soon as it arrives, the sending device embeds a future playback timestamp in the stream. Every endpoint holds audio in its buffer until that shared timestamp arrives, then plays simultaneously. This is what Sonos calls its proprietary synchronisation layer, what Apple formalised in AirPlay 2, and what Google Cast (with some caveats) approximates. Done well, it reduces inter-zone drift to low single-digit milliseconds. Done poorly, or when network conditions stress the system, it falls apart.

How each major ecosystem handles sync

Sonos built synchronisation into the platform from the beginning, which is a genuine advantage. Every Sonos device shares a network time reference using a protocol similar to PTP (IEEE 1588 Precision Time Protocol) over the local LAN. When zones are grouped, the system nominates a leader that schedules playback timestamps, and endpoints reference that shared clock. In a wired environment, or on a clean Wi-Fi network, Sonos group sync is genuinely excellent — well under 5 ms between zones in my own testing with a measurement mic and a signal generator. It holds up well under moderate network load.

AirPlay 2 uses a comparable approach, embedding NTP-referenced timestamps in the RTP audio stream. The difference is that Apple's implementation relies on the endpoints having a reasonably accurate shared time reference from an NTP server — typically Apple's own infrastructure — rather than a local leader device. Under normal home conditions this is fine. But I've seen AirPlay 2 sync degrade noticeably when a router's NAT table is hammered by torrent traffic or when a cheap access point is doing heavy QoS queuing. The system can recover, but recovery introduces a brief audio dropout rather than a gradual drift correction, which is its own kind of annoying.

Google Cast is the most variable of the major three. On paper it supports multi-room sync via the Cast protocol's group playback mechanism. In practice, the sync quality depends heavily on whether you're using a first-party Google device (where the firmware is known and tested) or a third-party Cast-certified product. Some of the cheaper Cast-enabled soundbars I've encountered drift by 30–50 ms in a grouped session within minutes. That's not a network problem; it's a firmware implementation problem. The Cast spec gives manufacturers latitude in how they implement the timestamp-scheduling layer, and some take more latitude than is good for the listener.

BluOS (used by NAD, Bluesound, and a number of other brands) and WiiM both handle sync via their own timestamping layers over the local network. Both have improved significantly over the last couple of firmware generations. WiiM in particular has made a point of publishing inter-zone sync specs in their release notes, which I respect — it suggests they're actually measuring it. HEOS (Denon/Marantz) has historically been the weakest of the mainstream systems for multi-zone sync, though recent firmware has addressed some of the worst offenders.

If you're running a Marantz or Denon integrated with HEOS and want to know how it handles multiroom, our review of the Marantz Model 40n (check price) touches on the HEOS implementation in a real two-zone setup. Short version: it's fine for background listening, less satisfying when you're walking between rooms with a real track playing.

The role of your network — and why Wi-Fi 6 helps less than you'd think

The most common advice you'll read online is "upgrade to Wi-Fi 6 and your sync problems will disappear." I'm going to push back on that. Wi-Fi 6 (802.11ax) improves aggregate throughput in dense environments and introduces Target Wake Time for battery devices, but for a handful of low-bitrate audio endpoints, the bottleneck is almost never raw bandwidth. A lossless 24/96 stereo stream is around 4.6 Mbps. Even an elderly 802.11n access point handles that trivially.

What actually matters for sync is latency consistency, not bandwidth. The enemies are: high retry rates (caused by poor signal or interference), deep buffering in budget routers, and anything that disrupts the timing of packet delivery. A well-configured 802.11ac (Wi-Fi 5) mesh network will outperform a poorly configured Wi-Fi 6 setup for multi-room audio every time.

We covered the ethernet-versus-Wi-Fi question in detail in our piece on the best DACs and network streamers, but the short version for multiroom is: if you have the option to run ethernet to even one or two of your endpoints, do it. Wired devices introduce far less jitter into a grouped session, and in Sonos's architecture, a wired device tends to be nominated as the sync leader, which pulls the whole group's stability up.

Diagnosing drift in your own system

You don't need specialist gear to tell whether your zones are syncing properly. Here's what I actually do. Play a mono signal — a podcast, a speech track, anything with clear transients — across two zones simultaneously. Walk slowly between the two playback areas. If you hear a clear comb-filtering effect (the sound going hollow, then bright, as you move through the overlap zone), the zones are close in time but not perfect. If you hear a distinct echo, they're badly out of sync. The audible threshold is roughly 10–15 ms at normal listening distances; anything worse than that is fixable.

A more rigorous approach: play a track simultaneously across zones, and use a phone running an audio analyser (I use Room EQ Wizard mobile, though a simple oscilloscope app works) near each speaker in turn. Record screenshots of the waveform. If you have the patience to do this properly, use a click track with sharp transients — the offset between the two recordings gives you the inter-zone latency in milliseconds. It's a bit involved, but once you've done it you have an actual number to work with.

Common culprits I've found in client systems: a single 2.4 GHz-only endpoint dragging down sync for the whole group (2.4 GHz is slower to retransmit and more congested in suburban environments); a router's upstream QoS treating audio packets as bulk traffic; and — more often than you'd expect — a device with a pending firmware update that has a known sync regression. Check firmware first. Always.

Practical fixes, in rough order of effort

Update firmware across all endpoints before anything else. I mean all of them — including the router. This fixes more problems than any hardware change. Then check whether your problematic endpoints are on 2.4 GHz when they could be on 5 GHz. Most modern devices will prefer 5 GHz automatically, but older kit sometimes doesn't. Force it if your access point allows per-device band steering overrides.

If you're running a mesh system, make sure backhaul is on a dedicated band or a wired connection rather than the same radio serving clients. A mesh node doing double duty as a client radio and a backhaul radio is introducing extra queuing delay on every hop. Budget mesh systems often don't separate these, which is one reason they underperform in multiroom scenarios despite having nominally excellent throughput specs.

For Sonos systems specifically: if you have a mix of wired and wireless nodes, the system's sync leader election should naturally favour the wired device. If it doesn't seem to be doing so, a factory reset of the wireless endpoint and a fresh group setup sometimes resolves persistent drift that firmware updates haven't fixed. Annoying, but effective.

Some ecosystems — WiiM is the clearest example — offer a manual latency offset adjustment per zone in the app. This is a blunt instrument: you're not fixing the root cause, just compensating for a known fixed offset. It works perfectly well when the drift is consistent, and not at all when drift is variable. Use it as a last resort, not a first response.

When the ecosystem itself is the limit

Honestly? Some multiroom platforms just aren't built for tight zone sync. If you're running a mix of Cast-certified third-party devices from different manufacturers, expecting sub-10 ms sync across all of them is probably optimistic. The more homogeneous your ecosystem, the better the sync. Mixing AirPlay 2 devices from three different brands in one group session is asking for trouble, particularly when one of them is a smart display that's running a lightweight Cast client alongside seventeen other background processes.

If whole-home sync is genuinely the priority — if you're building a system where you expect to walk through the house and have music track you without a phase artefact — then the honest recommendation is a purpose-built platform: Sonos, a single-brand BluOS system, or a dedicated commercial install running something like a streaming amplifier architecture with a centralised source. Mixing and matching is fine for background music in independent zones. It's a compromise for true room-to-room continuity.

The underlying physics here don't change regardless of marketing. Audio sync over a shared-medium wireless network is a distributed coordination problem, and distributed coordination problems are hard. The platforms that solve them well have invested heavily in the timing layer. The ones that haven't will drift. A spec sheet that says "multi-room grouping supported" tells you nothing about which camp a device falls into — and that's worth knowing before you build a system around it.