Skip to main content
sigh
Prodigy II
Aug 18, 2024 10:20 PM UTC

Investigating my wonky groups

After deciding to sacrifice my unused Sonos speakers to the upgrade gods, it didn't take long to run into an issue.

Playing back music, I had repeatable on demand issues

  • If a group contained 4 or more devices, there is a delay of up to 12 seconds or music dropping in and out during the first 12 seconds on all devices except the group controller when starting music or changing tracks. By devices that includes a sub and/or stereo pairs, not 4 sonos rooms.
  • Changing group members in the app gets slow after the above and playing music. Track progress starts getting jumpy, cloud api calls take longer.

I have spent some time investigating and think I know what is causing my speakers to have issues while grouped, which also introduces random app behaviour, cannot contact messages, slow responding. More often than not, once the controller gets into a state it doesn't recover and requires fully closing and reopening to return to normal.

Why I didn’t instantly assuming it was my network

  • For the past 3 years my Sonos has been completely trouble free, unless I was fiddling in my network settings and broke something myself. I have visibility on data about most parts of my network, so it’s usually obvious when something is wonky

Changes of note during past year

  • I no longer have my Sonos amps, port or one of the subs - the lack of port may have contributed
  • I have added some Yamaha gear which uses multicast, including from my HT AVR → Sub, so it is obvious when multicast is playing up because the avr and sub separate.
  • I replaced my noisy all singing all dancing enterprise managed POE switches for more suitable, fanless managed SMB switches about a year ago. Far less settings to fiddle and break things with 😊
  • Following the upgrade was the first time I added a wifi network for a while. I’ve been on SonosNet for over a year. Maybe time to blame the missing port again 😁
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

52 replies

sigh
sighAuthor
Prodigy II
Aug 20, 2024 12:56 AM UTC

Hi @sigh, great analysis as always. I was typing a reply to say “no way are any of your Sonos devices using 802.11a” when I read this …

https://support.sonos.com/en/article/supported-wifi-modes-and-security-standards-for-sonos-products

… and I stand corrected! Also surprising to see how few Sonos devices support 802.11ac (aka Wi-Fi 5) which was broadly rolled out in routers a decade ago.

You and me both 😂 Ikea gen 1 were released in 2019, so it never crossed my mind it would have such an old version. It was 2021 before they release the gen 2 and picture frames with N.

Looking at the availability dates of Sonos products, I suspect the Ikea Gen 1 products have a hardware board based on or from the Sonos One. During the Sonos/Ikea development and production run phase for it’s 2019 release, the 11a would have been the Sonos One production version.

Using 5Ghz at least when the 11a and 11n devices connect they should run at the correct speeds. Unlike 2.4Ghz where things usually run at slowest connected device speed without airtime fairness.

Translate
Local Superstar
Aug 20, 2024 7:28 AM UTC

The group coordinator the needs to retrieve the file/stream and send to the other devices to play. The group coordinator isn’t streaming the source at playback speed it is retrieving much faster into a local buffer, while also trying to send data to the group members, who will most likely also have a buffer to fill.

 

Not quite, the stream is unicast to the coordinator, the other players in group on same AP channel will listen in in promiscuous mode, so there is extremely little increase in bandwidth, as the other group players are receiving the same packet. It is only sent to other players that are not on same AP or channel.

If you had say 6 players all connected to a single AP using 2.4Ghz, streaming Apple Music lossless 48/24, you would see a single ~3Mb/s flow to the coordinator. 

Translate
Prodigy III
Aug 20, 2024 7:57 AM UTC

 

I think you may be onto a critical underlying challenge: the much chattier APIs in the new app / new device firmware present tremendous bandwidth issues for the 802.11n protocol used by the majority of contemporary Sonos device.

For me the concern is more if the behaviour of playback has changed when using the newer API’s that the new app would call. If that process has become chattier (for example sending more data back to Sonos so their web services have more information) then potentially that’s a fundamental design flaw in this new world? Especially if it does turn out to part of the new set of issues. 

I say *if* purely because what @craigski posted makes some sense, as if it were purely down to bandwidth then how did Sonos ever work in the first place? Broadcasting to other nodes seem logical, and also I would expect that group playing has always had a degree of chatter between players to keep stuff in sync? 

Translate
Prodigy III
Aug 20, 2024 8:26 AM UTC

Unfortunately that is just the totals, so without being able to get a more detailed breakdown of the network stats or capture what the bridge is seeing using additional tools it is hard to say. 

There can be various reasons including but not limited to

  • software bridges have input/output buffers, so the input buffer could be near full and receiving bursts of traffic larger than the free space
  • there could be unknown packet or protocols being received, some smart home devices send out regular bursts of traffic with a custom protocol type for example.
  • if there are firewall rules on the bridge they could drop traffic

Identifying things like is it a regular repeating increase every X minutes, is it only when playing music, is it all the time may help point in directions, but without being able to see the details of what/why it’s dropping it’s going to be a tricky one to pinpoint.

As for why the play 3 is the odd one out, without a better idea of what is being dropped it’s difficult to know whether it is traffic the 3 would even receive. Maybe it’s filtering it out before the reaching the 3, maybe the 3 is the source 😃

On 1, I’d expect the Play:3 to have the least amount of network buffer as the oldest most RAM deficient player in the system, so not sure it can be that, and I’m not aware of any firewalls that would be selectively protecting the Play:3 over and above the other products on the same subnet. 

Overnight the same device I quoted stats for has dropped another 80k packets whilst not being used for any playback, and I notice that the actual eth0 interface which I presume is the actual physical interface (this player is ethernet connected with WiFi off) has only dropped 11 packets which is of little concern. 

It’s interesting again though on the Play:3 that it’s not reporting the physical interface it must be using…

 

running /sbin/ifconfigath0      Link encap:Ethernet  HWaddr 00:0E:58:76:DA:B6            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:199           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)          Interrupt:16 Memory:c52c0000-c52e0000 br0       Link encap:Ethernet  HWaddr 00:0E:58:76:DA:B6            inet addr:192.168.11.193  Bcast:192.168.11.255  Mask:255.255.255.0          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:12465121 errors:0 dropped:0 overruns:0 frame:0          TX packets:2249347 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0           RX bytes:312345171 (297.8 MiB)  TX bytes:1341937611 (1.2 GiB)eth0      Link encap:Ethernet  HWaddr 00:0E:58:76:DA:B6            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)          Base address:0x4000 lo        Link encap:Local Loopback            inet addr:127.0.0.1  Mask:255.0.0.0          UP LOOPBACK RUNNING  MTU:16436  Metric:1          RX packets:2889 errors:0 dropped:0 overruns:0 frame:0          TX packets:2889 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0           RX bytes:704309 (687.8 KiB)  TX bytes:704309 (687.8 KiB)

It’s only reporting the bridge interface. My other devices are One (Gen 1), One SL, 2 x Port and a Move.

The Gen 1 One, seems to be a halfway house… it’s showing the dropped packets on the bridge interface unlike the Play:3, but like the Play:3 no physical interface that’s feeding it… 

The rest all report a selection of WiFi/Eth interfaces alongside the bridge interface with 1 physical interface showing a large number of actual packets with a low dropped count. 

So could just be a software bug on the Play:3/One support interface I suppose, but it’s clearly behaving differently to the rest. 

All players are on 5GHz connections all showing a strong connection according to the Sonos App. 

Translate
Local Superstar
Aug 20, 2024 8:37 AM UTC

Not all devices are created equal. If you have a mix of old and new and an old one is the group controller, it's going having a touch time with lossless and higher content. If your wifi design (quite possibly antenna) causes lower than max connection rates, then again the group controller will have a hard time.

An older device wont support higher bit rates from Apple Music

https://support.sonos.com/en-gb/services/apple-music

Most Sonos products can stream lossless audio from Apple Music. However, some older products don’t support the required streaming protocol (HLSv7) and will stream audio at a lower quality. The following Sonos products won’t stream lossless audio from Apple Music:

  • Connect (Gen 1)
  • Connect:Amp
  • Play:1
  • Play:3
  • Playbar
  • Playbase
  • Sub (Gen 1)

 

If you recall when some of those products were released, it was around the same time as Apple iPhone 5s? Apple doesn’t support lossless on an iPhone 5s 😀

If you stream lossless to a group, then add an older product, it will downgrade the stream, you may hear a pause in the transition.

I don’t get many issues streaming using the Sonos Apple Music service, even with multiple streams. I have old and new products, when the stream changes due to adding an older product, I will get a short pause. Once you understand this, you can work around it.

Translate
Local Superstar
Aug 20, 2024 10:40 AM UTC

It's easy saying lots of the things and almost making the maths fit the issues (or vice versa..) but don't forget these issues were not anything like as prevalent pre-update and the hardware seemed to cope OK.

For years, many questioned the lack of progress in the hardware (especially WiFi generation and the continued use of 10/100 ethernet ports that probably were even harder to source and possibly more costly!).

Maybe there's going to be a price to pay for the conscious lack of hardware progression prior to the last generation or two.

Translate
Enthusiast II
Aug 20, 2024 12:44 PM UTC

It's easy saying lots of the things and almost making the maths fit the issues (or vice versa..) but don't forget these issues were not anything like as prevalent pre-update and the hardware seemed to cope OK.

For years, many questioned the lack of progress in the hardware (especially WiFi generation and the continued use of 10/100 ethernet ports that probably were even harder to source and possibly more costly!).

Maybe there's going to be a price to pay for the conscious lack of hardware progression prior to the last generation or two.

That’s what Spence wants and needs  - ‘buy our shiny new hardware’

 

Again

Translate
Local Superstar
Aug 20, 2024 1:05 PM UTC

Yes, maybe, but that not hugely different to other businesses?  Ultimately, if people don't buy new hardware, businesses die.

My point was more along the lines of, while we can look at the figures and start to think ‘It's hardly surprising it's all falling over, look at the amount of data being handed around…’ etc., we mustn't forget that things for most worked just fine beforehand with the same setup.

Translate
Prodigy III
Aug 20, 2024 1:07 PM UTC

Maybe there's going to be a price to pay for the conscious lack of hardware progression prior to the last generation or two.

It’s a key thing to understand though… if that hardware is on the cusp of not being able to support the new ecosystem, and causes instability, then to be honest it strengthens the calls for the old S2 app to come back, and the new one be rebranded as S3, dropping support for that hardware. 

Now I’m sure that would bring about further consternation and hand wringing, but at least people could get back to a working setup without then needing to go on an upgrade spree. 

Translate
Enthusiast II
Aug 20, 2024 8:01 PM UTC

Maybe there's going to be a price to pay for the conscious lack of hardware progression prior to the last generation or two.

It’s a key thing to understand though… if that hardware is on the cusp of not being able to support the new ecosystem, and causes instability, then to be honest it strengthens the calls for the old S2 app to come back, and the new one be rebranded as S3, dropping support for that hardware. 

Now I’m sure that would bring about further consternation and hand wringing, but at least people could get back to a working setup without then needing to go on an upgrade spree. 

Maybe some of the apologists would change tack! 😆

Translate