TL;DR
Music skips because two specific speakers — Living Room Max and Guest Bathroom Mini — have catastrophically bad Wi-Fi paths (avg ~80 ms, spikes to 350–520 ms, 5% packet loss vs ~4 ms / 0% loss for healthy speakers in the same house). Grouped audio gets staticky because Google Cast Group sync waits for the slowest member — if either bad speaker is in a group, the whole group destabilizes. Layered on top: 118 devices on a flat /22 subnet flooding 2.4 GHz with multicast chatter. Fix the two speakers first (move / power-cycle / rebuild groups without them), then address the structural noise.
Per-speaker latency (60-second ping from wired M4 → speaker)
Wired source → mesh-attached speaker. RTT spikes & stddev are a direct proxy for the speaker's Wi-Fi quality to its pod. Music streaming buffers ~40 ms of audio — when RTT spikes blow past that, you get skips.
| Speaker | IP | Loss % | Avg ms | Max ms | Stdev | Verdict |
|---|---|---|---|---|---|---|
| Living Room (Max) | 192.168.6.107 | 0 | 78 | 351 | 105 | Broken — main listening surface |
| Guest Bathroom (Mini) | 192.168.4.77 | 5.6 | 94 | 520 | 166 | Broken — actual packet loss |
| Master Closet (Mini) | 192.168.4.58 | 0 | 25 | 139 | 35 | Marginal |
| Kendyl (Mini) | 192.168.4.80 | 0 | 29 | 88 | 27 | Marginal |
| Kynsie bedroom (Mini) | 192.168.4.74 | 0 | 14 | 105 | 25 | Noisy spikes |
| Outside (Nest Audio) | 192.168.4.173 | 0 | 12 | 148 | 34 | Noisy spikes |
| Kitchen (Max) | 192.168.5.102 | 0 | 11 | 107 | 25 | Noisy spikes |
| Master Bath Clock (Hub) | 192.168.4.64 | 0 | 17 | 45 | 14 | OK |
| Master Bedroom (Nest Audio) | 192.168.4.56 | 0 | 6 | 11 | 2 | Excellent |
| Office (Nest Audio) | 192.168.4.60 | 0 | 4 | 20 | 4 | Excellent |
| Garage (Nest Audio) | 192.168.4.59 | 0 | 4 | 7 | 1 | Excellent |
Healthy speakers (Office, Garage, Master Bedroom) sit at 4–6 ms avg with sub-2 ms stddev. The two broken ones are 15–25× worse on every metric. Same network, same DHCP server, same DNS — the difference is the RF path from each speaker to whatever eero pod it's associated with.
Three things are happening at once
1. Two speakers have bad RF paths to their pod
Living Room Max and Guest Bathroom Mini are either too far from the nearest eero pod, behind too much attenuation (granite, ductwork, tile, mirrors), or sitting on a saturated 2.4 GHz channel. Their 60-second jitter is 100+ ms — there's no streaming codec that survives that without skipping. This alone explains the single-speaker skipping.
2. Grouped audio waits for the slowest member
Google Cast synchronizes group playback to a master clock; the buffer size is set by the highest-latency speaker in the group. When Living Room Max spikes to 351 ms, every speaker in the same group has to either delay (you hear a gap) or play stale audio (you hear static / a glitch). Drop the two broken speakers out of any cast group and the staticky-grouped-audio symptom should largely disappear.
3. The network is structurally noisy under it all
118 devices on a flat 192.168.4.0/22 subnet. Every Aqara camera, Ring sensor, Kasa plug, Tuya device, and Google speaker is on the same broadcast domain — they all emit and consume mDNS announcements at 6 Mbps multicast rate (the lowest 2.4 GHz basic rate). On a quiet network this is fine; here it's a constant tax on every Wi-Fi client. Marginal speakers tip into broken under this load.
Speaker fleet map
Fix plan — three tiers
Tier 1 — Tonight (5–10 min, zero cost)
- Power-cycle Living Room Max and Guest Bath Mini. 30 s unplugged each. Forces them to re-associate with whatever eero pod is actually closest right now (they may be stuck on a far one).
- Open Google Home app → check each Cast Group → remove Living Room Max and Guest Bath Mini from every group temporarily. If grouped audio gets clean immediately with them out, that confirms the sync-to-slowest-member theory.
- Walk to each problem speaker and check the eero app for "Connected to" pod. If Living Room Max is connected to the upstairs / far pod instead of the nearest one, the eero band-steering or a sticky-client problem is at play.
Tier 2 — This week (eero app + maybe a pod move)
- eero app → Settings → Advanced → Wi-Fi network → Local network access: confirm IGMP / mDNS proxy is on (it is by default in modern eero firmware, but worth verifying after the post-segmentation tinkering).
- Check eero firmware version in the app. eero ships mesh / multicast handling fixes every few releases — if it's been a while since auto-update fired, force one.
- Relocate or add a pod near the Living Room. An eero Pro 6E / Pro 7 within 15 ft of the Living Room Max — line-of-sight, not behind the TV — would change the entire music experience. This is the single highest-leverage move. (You have eero Pro hardware already — the question is whether an existing pod can be repositioned, or whether to add one more.)
- Guest Bathroom Mini: bathrooms attenuate Wi-Fi badly (tile, mirror). Either move the Mini closer to the bathroom door, or accept that it's a casualty and pull it from groups.
Tier 3 — Structural (worth opening a ticket for)
- Dedicated 2.4 GHz IoT SSID — same idea as the spa BWA fix would have wanted.
eero on a single SSID will continue to fight band-steering decisions across 60+ IoT devices. A
second SSID locked to 2.4 GHz, named e.g.
SpoiledBoxers-IoT, for everything that doesn't need 5 GHz (Minis, Aqara cams, Ring, Kasa). The Maxes stay on the main SSID so they get 5 GHz. eero only added this in 2024; check if your hardware supports it. - Subnet hygiene — 118 devices on /22 is a lot of mDNS chatter. eero won't let you change subnet mask easily, but enabling "Local network privacy" toggles for chatty devices, and verifying Aqara cameras aren't multicasting unnecessarily, both help.
- Long game: AirPlay-first listening. The Living Room and Kitchen Maxes are the only 2 devices in the fleet that really need to sound great. A pair of AirPlay 2 speakers (or a Sonos pair, on Jaime's wish-list per the inventory) plugged into a strong pod is more reliable than Cast on a busy mesh — Apple's stack handles RF flakiness better. Filed for later, not urgent.
Cross-reference to existing context
- The spa-resilience diagnosis from this morning (OPS-109) flagged the same root pattern: a 2.4 GHz client either roaming poorly or being steered off its best pod by eero. Living Room Max may be a second instance of the same eero behavior. Worth measuring the dropout cadence the same way — regular periodicity → eero steering; random bursts → speaker firmware.
- The 2026-04 security hardening disabled IPv6 and tightened the network. None of that should affect Cast (which is IPv4 + mDNS), but worth keeping in mind.
- Speakers stay — per the anti-Google smart-home memory, this is the one Google-cloud surface that's explicitly NOT in scope for replacement. Fix the network, keep the speakers.
Tickets filed: OPS — rescue Living Room Max + Guest Bath Mini · OPS — eero 2.4 GHz IoT SSID exploration. See Linear for status.