Skip to main content

Choppy playback, lost speakers

  • May 19, 2026
  • 11 replies
  • 88 views

Let me start out by saying I think I have read every possible article related to choppy playback, wifi interference, losing speakers, and best practices. I have been fighting this issue for the better part of a year at this point. From a network standpoint, I have used a single Netgear router with built-in wifi, a Fortinet gateway controlling Fortinet APs, an Amplifi router with a mesh remote, a Deco 3 AP system with both wireless and wired backhaul, and finally I am now on Unifi, with the gateway, switch and wired APs. All have exhibited the same experience where grouping speakers together can take a long time or fail completely. When speakers are grouped, the choppiness happens consistently and most times ends up causing the entire system to stop playing altogether. Now that I am on full Unifi equipment, I have taken care to try to configure it both to Unifi’s best practices and to Sonos’ best practices with no luck. Here are my latest troubleshooting notes.

Sonos + UniFi Troubleshooting Write-Up

Date: May 18, 2026
Hardware: UCG-Max (UniFi OS 5.0.16), UniFi Network 7.4.1, 2x U7 Pro APs, USW Pro Max 24 PoE
Issue: Sonos grouping failures, spinning circle when grouping/ungrouping, slow volume response, dropout during playback, devices dropping from groups

Environment

Network

  • Gateway: UniFi Cloud Gateway Max (UCG-Max)
  • Switch: USW Pro Max 24 PoE
  • Access Points: 2x U7 Pro (Upstairs and Downstairs), both on firmware 8.5.21
  • Sonos SSID: XXXXX (dedicated SSID for Sonos devices)
  • Sonos VLAN: VLAN40-IOT

Sonos Devices (18 total)

All devices on VLAN40-IOT (10.0.40.x), all connected to XXXXX SSID:

Device Fixed IP Generation
Family Room Playbar .60 Legacy
Family Room Sub .61 Legacy
Family Room Play:1 Left .62 Legacy
Family Room Play:1 Right .63 Legacy
Kitchen Era 300 .64 Era (WiFi only)
Bathroom (Sonos One) .65 Legacy
Master Bedroom Play:1 Left .66 Legacy
Master Bedroom Play:1 Right .67 Legacy
Symfonisk Right .68 Legacy
Symfonisk Left .69 Legacy
Master Bedroom Sub .70 Legacy
Living Room Sub .71 Legacy
Living Room Playbar .72 Legacy
Living Room Play:1 Left .73 Legacy
Living Room Play:1 Right .74 Legacy
Office Era 100 Right .75 Era (WiFi only)
Office Era 100 Left .76 Era (WiFi only)
Office Sub .77 Era (WiFi only)

Sonos Groups

  • Living Room: Playbar + Play:1 Left + Play:1 Right + Sub
  • Family Room: Playbar + Play:1 Left + Play:1 Right + Sub
  • Master Bedroom: Play:1 Left + Play:1 Right + Sub (no Playbar)
  • Office: Era 100 Left + Era 100 Right + Sub
  • Standalone: Kitchen Era 300, Bathroom, Symfonisk Left, Symfonisk Right

Initial Findings

VAP Statistics (Before Any Changes)

On the XXXXX SSID, Upstairs U7 Pro had 11 Sonos devices all on 2.4GHz channel 11:

  • tx_retries: 92,668
  • tx_combined_retries: 144,467
  • rx_errors: 139,172
  • wifi_tx_dropped: 174
  • wifi_tx_latency_mov max: 97,000ms (97 second worst-case latency spike)
  • Downstairs AP had only 1 Sonos device - extreme imbalance

Root Causes Identified (most based on Best Practice Recommendation)

  1. No assisted roaming (802.11k/v) - devices stuck to congested AP
  2. No minimum RSSI - weak clients holding onto overloaded AP
  3. Few fixed IPs on any Sonos device - IPs drifting constantly
  4. Stale DHCP reservations from old/renamed devices causing IP conflicts
  5. IGMP snooping enabled on VLAN40-IOT - suppressing Sonos multicast
  6. All 18 Sonos devices on 2.4GHz only - massive airtime contention

Changes Made

1. Enabled Assisted Roaming (802.11k/v)

Applied to both U7 Pro APs on 2.4GHz radio. Allows APs to suggest better AP to overloaded clients.

2. Enabled Minimum RSSI (-75 dBm)

Applied to both U7 Pro APs on 2.4GHz radio. Devices weaker than -75 dBm are kicked to find a better AP rather than dragging down the whole group.

3. Fixed IPs Assigned to All 18 Sonos Devices

Set DHCP reservations for all devices at their intended IPs (.60 through .77). Cleared several conflicting stale reservations from old/retired devices.

4. Removed IGMP Snooping from VLAN40-IOT

IGMP snooping was suppressing Sonos multicast traffic during group formation, causing the burst of "Poor" experience ratings when groups formed and contributing to the 30-second grouping delay.

5. Enabled 5GHz Band on XXXXX SSID

This was the single biggest improvement. After enabling 5GHz, the Era-generation devices (Era 100, Era 300, newer Subs) automatically migrated to 5GHz, significantly reducing 2.4GHz channel 11 congestion. Legacy devices (Play:1, Playbar, older Sub) remained on 2.4GHz as they don't support 5GHz.

6. Enabled Fast Roaming (802.11r)

Applied to XXXXX SSID. Minimal observed impact.

7. Enabled Proxy ARP

Applied to XXXXX SSID. Minimal observed impact.

8. Minimum Data Rate

Set to 12 Mbps (Higher Density) on XXXXX. Minimal observed impact.

9. DHCP Lease Time

Reduced from 24 hours (86400s) to 2 hours (7200s) on VLAN40-IOT to help devices reclaim correct IPs faster after reconnecting.

 

Results After Changes

VAP Statistics Improvement

Metric Before After Change
tx_retries 92,668 67,599 ✅ 27% better
tx_combined_retries 144,467 89,925 ✅ 38% better
wifi_tx_dropped 174 17 ✅ 90% better
Max latency 97,000ms 94,000ms ➡️ Minimal change

Band Distribution After 5GHz Enabled

  • 5GHz (channel 149): Era 100s, Era 300, newer Subs, Symfonisks
  • 2.4GHz (channel 11): Play:1s, Playbars, older Subs

Remaining Issues

  • Grouping still takes 10-30 seconds
  • Volume control still slow to respond
  • Experience ratings momentarily drop from Excellent to Good/Poor during group formation

Unresolved Issue - Playbar IP Drift During Group Bonding

Description

This is the core remaining problem. Both theater Playbars (Living Room and Family Room) consistently grab incorrect IPs specifically when their surrounds and sub are bonded to them.

Observed pattern:

  • When surrounds/sub are ungrouped from Playbar: all devices show correct IPs
  • When surrounds/sub are bonded to Playbar: Playbars grab their satellites' IP addresses, satellites disappear from UniFi client list

Example:

  • Living Room Playbar (should be .72) grabs .73 (Play:1 Left's address)
  • Family Room Playbar (should be .60) grabs .62 (Play:1 Left's address)
  • The bonded satellites (.71, .72, .73, .74 / .60, .61, .62, .63) disappear from UniFi entirely

What I've Tried to Fix This

  • Set fixed IP reservations via API - Playbar ignores reservation after bonding
  • Forget device and re-add with fresh reservation - works temporarily, reverts after bonding
  • Shorter DHCP lease time (7200s) - may help going forward, doesn't fix current behavior
  • Power cycling Playbars - temporarily corrects IP until next group bond

Hypothesis

When Sonos bonds satellite devices (surrounds, sub) to a Playbar, the satellites temporarily drop off WiFi and communicate through the Playbar's internal coordination channel (SonosNet on legacy devices). During this process, something in the Playbar's DHCP behavior overrides the UniFi fixed IP reservation and it claims whatever IP it last saw its first satellite register with.

This behavior is consistently reproducible and appears to be triggered specifically by the Sonos group bonding process, not by network instability.

Important Context - Mixed Generation Devices

The system has a mix of legacy Sonos devices (Playbar, Play:1, older Sub - support SonosNet) and Era-generation devices (Era 100, Era 300, newer Sub - WiFi only, no SonosNet). Wiring the legacy Playbars is not a viable solution because:

  • Wired legacy devices become SonosNet access points
  • Era devices cannot join SonosNet
  • This creates two separate communication paths within the Sonos system, which causes additional coordination issues between the generations

Questions for Community

  1. Is this Playbar IP grabbing behavior a known issue with UniFi + Sonos?
  2. Is there a UniFi-specific DHCP setting that forces reserved IPs to be honored even when a device requests a different address?
  3. Has anyone found a reliable way to prevent bonded Sonos groups from causing IP drift in UniFi?
  4. Is there a Sonos-side setting that controls how the Playbar coordinates DHCP during group bonding?

Hardware/Software Versions

  • UCG-Max: UniFi OS 5.0.16
  • UniFi Network: 7.4.1
  • U7 Pro firmware: 8.5.21.18681
  • All Sonos devices: Latest available firmware as of May 2026

11 replies

  • Author
  • Contributor I
  • May 19, 2026

Update to correct: 
 

Hardware/Software Versions

  • UCG-Max: UniFi OS 5.0.16
  • UniFi Network: 10.3.58
  • U7 Pro firmware: 8.5.21.18681
  • All Sonos devices: Latest available firmware as of May 2026

Pools-3015
Forum|alt.badge.img+17
  • Prodigy I
  • May 20, 2026
  1. Hardwire the Playbars and leave their WIFI enabled 
  2. Enable IGMPSnooping and multicasting 
  3. Disable fast roaming and assisted roaming. You don’t need them enabled because your speakers are not moving around like your phones.
  4. Enable RSTP and set the right priority on the switches

Stanley_4
  • Grand Maestro
  • May 20, 2026

Can't even begin to help with that, but older Sonos wired to Ethernet, without the Wi-Fi disabled, creates Sonosnet and will pull other older devices off the Wi-Fi to it. For me that was a problem and removing it  made things better.


buzz
  • May 20, 2026

STP rather than RSTP.


Pools-3015
Forum|alt.badge.img+17
  • Prodigy I
  • May 20, 2026


I Had STP enabled but tried RSTP on a recommendation from a network engineer. I have not had any issues with this setting 


Forum|alt.badge.img+18
  • Local Superstar
  • May 20, 2026

 

Questions for Community

  1. Is this Playbar IP grabbing behavior a known issue with UniFi + Sonos?
  2. Is there a UniFi-specific DHCP setting that forces reserved IPs to be honored even when a device requests a different address?
  3. Has anyone found a reliable way to prevent bonded Sonos groups from causing IP drift in UniFi?
  4. Is there a Sonos-side setting that controls how the Playbar coordinates DHCP during group bonding?

 

 

There is no need to ‘reserve’ IP addresses on a Sonos deployment using most consumer routers. Trying to reserve in a Sonos HT setup, you will see issues such as ARP Spoof detection, when the satellites/subs bond. Most DHCP servers in consumer routers (including UniFi) use dnsmasq as the DHCP server. This will hash the MAC address using some clever mathematical formula to allocate an IP address. As the MAC address remains same, the IP address will be consistent, even though it is not reserved. If you have what appear random (non sequential) IP addresses, you are using dnsmasq. There is a small chance of clash, but an alternative IP address will be offered. This is not the cause of your symptoms.

I would also disable BSS Transition & ARP Proxy.

Its not clear from your detailed write up if are using Ethernet for any Sonos devices? If so it will be an STP misconfiguration issue causing the issue(s) you are seeing.

By coincidence, Ubiquiti are releasing a training video on STP configuration on their academy website site today:

https://academy.ui.com/

If you have reasonable WiFi coverage where the speakers are, I would consider unplugging all Sonos speakers, and use them in WiFi mode, this will avoid STP (re)configuation on your network.


Stanley_4
  • Grand Maestro
  • May 20, 2026

Sadly for some local networks reserved Sonos addresses are needed for stability.

If I don't have them I get update/reboot/power-fail issues. 

I can't even guess what DHCP code the Sonos devices are running internally but I suspect that more than a router issue.


Forum|alt.badge.img+18
  • Local Superstar
  • May 20, 2026

Sadly for some local networks reserved Sonos addresses are needed for stability.

If I don't have them I get update/reboot/power-fail issues. 

Your router is not using dnsmasq then and/or have a DHCP configuration issue. The whole point of dnsmasq is you will get the same IP address even after a reboot, as the mathematical hash of MAC will give consistant IP address.

The OP is using UniFi DHCP,  there is no ‘stability’ requirement to reserve IP addresses using a UniFi DHCP server, or most consumer routers, ISP supplied routers, etc that are using dnsmasq.


Forum|alt.badge.img+18
  • Local Superstar
  • May 20, 2026

 

By coincidence, Ubiquiti are releasing a training video on STP configuration on their academy website site today:

https://academy.ui.com/

 

Video is now live, note that there is a ‘Smart Speaker’ in the video. Ironically, they have used a picture that looks like a Era-100 (that doesn’t create a separate Sonos Network)

https://academy.ui.com/topics/switching-routing-and-why-stp-exists

 


Stanley_4
  • Grand Maestro
  • May 20, 2026

Sadly for some local networks reserved Sonos addresses are needed for stability.

If I don't have them I get update/reboot/power-fail issues. 

Your router is not using dnsmasq then and/or have a DHCP configuration issue. The whole point of dnsmasq is you will get the same IP address even after a reboot, as the mathematical hash of MAC will give consistant IP address.

The OP is using UniFi DHCP,  there is no ‘stability’ requirement to reserve IP addresses using a UniFi DHCP server, or most consumer routers, ISP supplied routers, etc that are using dnsmasq.

Yet without them I have issues, with them no issues.

The pfSense router is running Free BSD 16 and the ISC DHCP server.


106rallye
Forum|alt.badge.img+18
  • May 20, 2026

The speaker is a One, that does do Sonosnet. ;-)