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
Page 1 / 3
So why would 4 devices cause it to take up to 12 seconds for group members to stabilise and play when the coordinator plays constantly?
The issue only consistently occurred when the stream changed. So starting to play, changing track.
Adding/removing group members seemed more random. Most of the time they would join without issues.
If left to play an album or playlist, the disturbance only occurred within the first 12 seconds, then never again.
Volume worked perfectly all the time
That sounds like some sort of change in the other group members or the stream being modified/shaped as more players are added.
Receive buffer being increased in group members? Has to be something which doesn't interrupt the coordinator because that plays perfectly, so not on the fly compression, that would affect everything.
Due to having to reset the first 4 speakers to add wifi settings, my local library wasn't available so I'd been using Qobuz as my only source. Switching back to SonosNet to remove wifi and all it's fun and games from the equation, I checked the Network Matrix.
ODFM 0 for everything
Noisefloor between -100 and -110 for everything
Green boxes everywhere. This looked better connected than my previous years of yellow boxes that worked.
One concern on wifi, the RX/TX rates didn't look great. 54/24 and 60/130... what on earth is inside these things? Nothing great for the Gen 1 Symfonisks unfortunately
Hmmm, so I have 5 x 802.11a and 2 802.11n devices. What is wrong with that gen 2 bookshelf it only connects at 60/130 when n is capable of up to 600? What's the betting that Port I got rid of had a better wifi connection? And the group controller I'd been using only had 24 rx. on a good day with the wind behind it
Maybe the devices aren't doing anything funky with buffers or shaping, are the just being maxed out? How does the coordinator download the stream when playing?
Flac 16/44 - 3 tracksFlac 24/48 - 2 tracks
Well that's going to hurt 14/15Mbit initially which calms down until the whole track is cached, then -5 seconds before the next track same thing. So the first 12 seconds fits right in the initial burst when a stream changes and no player has anything in it's buffer. So if transmit was maxed sending to the group, until the buffer/cache files.
Starting before the current track ends would prevent a break in the stream so is seamless playing the whole album or playlist.
No bandwidth would also mean wonky controller and why adding the group member mid-track didn't impact.
What was I actually playing to test things? 24/44.1 and 24/48 albums as it turns out. Something the Sonos could actually retrieve from Qobuz, so wouldn't use the 16/44.1 version.
Right, need something smaller. No local library yet, so 16/44.1 flac it is. Flawless. Lets add more speakers until it breaks. 1 short of getting them all.
Now we're getting somewhere. What about a bit of Daft Punk, Qobuz provides as 24/88.2, so that means in reality Sonos plays the 16/44.1 flac. Again flawless.
So is this a firmware change that has altered the download behaviour? It's clearly being held back only reaching 17Mbps on the 24/48 albums and is lower for 16/44.1 What did I used to play to all 11/12 devices? Radio usually for background, so 128Kbps on a good day if really lucky 256kbit. And for 4 devices between two rooms. Definitely some of my 24/44.1 collection, but that would be full album and not in the same room when starting. So maybe it's always been this way. What did that update which fixed the volume control change? Websocket to the group so always a connection available?
While waiting for the library to index, time to find out what Yamaha and Airplay do different downloading 24/192 sources, because they did much better. Three notable things The yamaha gear and ipad have significantly faster wifi connections both up and down
Yamaha 24/1921st via bubbleupnp server, 2nd via iPad airplay
Yamaha pulls a max internet speed chunk in before starting to play and then 5-6 mbps chunks, so lower download Qobuz & Airplay doesn't even bother downloading if it's cached, then it's a fast chunk before limiting the speed. The first just catches that my dlna->openhome converter pulls everything asap, but it then streams to the devices at whatever rate they want.
Back to the local library, 330kbit mp3s first. Flawless to all speakers grouped.
What about a 16/44.1 flac... same device limit when streaming 16/44.1 from Qobuz
And a 24/48 concert track? Less speakers again.
Where does this fit with random behaviour we've been seeing across Sonos users?
Is this a firmware change that has altered the download behaviour? It's clearly being held back only reaching 17Mbps on the 24/48 albums and is lower for 16/44.1
What did I used to play to all 11/12 devices?
Radio usually for background, so 128Kbps on a good day if really lucky 256kbit.
And for 4 devices between two rooms. Definitely some of my 24/44.1 collection, but that would be full album and not in the same room when starting. So maybe it's always been this way.
What did that update which fixed the volume control change? Websocket to the group so always a connection available?
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.
Combine that with not knowing what bit rate you're actually streaming and the rise of lossless/hires content. On lower bandwidth wifi or SonosNet that puts a strain and with more speakers increases the likely hood of saturating what's available. Maybe that's why the Boost wasn't/isn't being supported in the brave new world. With the way the group controller downloads it doesn't take much to overload SonosNet if you have lossless content.
When the connections are saturated the controller can't get requests and responses from the devices. In the first volume slider dance people were suffering, when do most people change the volume of a track? At the beginning during the peak download rate maybe?
With Ethernet only devices you have more bandwidth than you'll ever need. A couple of separate SonosNets and an 802.11N nearer it's 600M max, you'll be wondering why everyone else is having troubles.
So between devices with different wifi capability, SonosNet that can't cope with lossless to more than a handful of devices and people streaming at many different bit/sample sizes, but not really knowing what, when can then send the controller app into an unresponsive or slowdown frenzy it doesn't recover from.
It's not much of a surprise trying to find commonality has been difficult. While it is ultimately network related, especially for SonosNet or the devices with old/odd wifi speeds, it's not something I'd expect to be for users to fix or even know.
It does raise even more questions in this increasingly bandwidth hungry streaming world, especially for those with devices that only have 54Mpbs Wifi connections.
Combine that with not knowing what bit rate you're actually streaming and the rise of lossless/hires content. On lower bandwidth wifi or SonosNet that puts a strain and with more speakers increases the likely hood of saturating what's available. Maybe that's why the Boost wasn't/isn't being supported in the brave new world. With the way the group controller downloads it doesn't take much to overload SonosNet if you have lossless content.
When the connections are saturated the controller can't get requests and responses from the devices. In the first volume slider dance people were suffering, when do most people change the volume of a track? At the beginning during the peak download rate maybe?
With Ethernet only devices you have more bandwidth than you'll ever need. A couple of separate SonosNets and an 802.11N nearer it's 600M max, you'll be wondering why everyone else is having troubles.
So between devices with different wifi capability, SonosNet that can't cope with lossless to more than a handful of devices and people streaming at many different bit/sample sizes, but not really knowing what, when can then send the controller app into an unresponsive or slowdown frenzy it doesn't recover from.
It's not much of a surprise trying to find commonality has been difficult. While it is ultimately network related, especially for SonosNet or the devices with old/odd wifi speeds, it's not something I'd expect to be for users to fix or even know.
It does raise even more questions in this increasingly bandwidth hungry streaming world, especially for those with devices that only have 54Mpbs Wifi connections.
Awesome work, @sigh, bravo!
I was on the edge of my seat throughout … cannot wait for the movie version.
It’s always fun to understand why things are broken. It’s why we all like major incidents at work, the customers and incident managers not so much
One thing I didn’t mention is what appeared to cause the controller app to corrupt the user data and one speaker to give up providing airplay. Nothing unusual from my perspective, my wifi access point needed a firmware update, so had to reboot.
The iPad unexpectedly losing wifi gave me a broken app. Doesn’t seem to be something unusual for a tablet. Walk out of range before sending it to sleep, restarting a wifi AP. Shouldn’t have to stop everything or shut it down to do that.
I tried deleting the app only, leaving user data. After reinstalling it was still broken the same way. Had to delete the user data as well, so something in there was corrupt and preventing the app launching enough to even make internet requests. First time I’ve had an app do that.
The wayward speaker seemed to get it’s software in a mess and when it rejoined wifi there was no airplay, just Sonos playback. All the others were fine.
I’m not sure I’m understanding what you’re saying the issue is, which is not to dispute your findings, just that I’m not getting my head round it.
16/44.1 is only around 1.4Mbps, 24/44.1 around 2.1Mbps and 24/48 will be around 2.3Mbps.
All of which are way below even an ancient 54Mbps WiFi connection’s theoretical maximums and hopefully still way under its achievable bandwidth with decent-ish signals.
One thing I’ve noticed on all my devices bar somewhat ironically the oldest Play:3 is that I get a large number of dropped packets on br0. Even on a relatively new Port which is ethernet connected with WiFi off… For example:
Now in general, everything seems to be ok, bar known functional limitations of the app, However, I don’t really understand why I’m getting so many dropped frames on all bar the Play:3? The Play:3 has actively been involved in groups with other speakers too, so isn’t used completely in isolation.
Does handling large amounts of dropped frames use more processing power? What’s ‘special’ about the Play:3 ?
So they issue I had is down to the 54Mbit Wifi Bandwidth when a track starts playing.
The bandwidth claimed on Wifi is unfortunately, always the theoretical max.
Wifi version
Theoretical (Mbit)
Real-World Average (Mbit)
11a (5Ghz)
54
~20
11g (2.4Ghz)
54
~20
11n (2.4 & 5Ghz)
150, 300, 450, 600 (depending on implementation)
40 (at 150) - 100 (at 600)
Among other things, when playing music the group coordinator retrieves the file/stream to play, decodes, plays locally and sends the data to the other devices in the group.
As you say Stereo 16/44.1 is ~1.4Mbit per second to play. From that outgoing bandwidth needed from the group coordinator is easy to work out. 1.4Mbps X number of member devices. 5 devices ~ 7Mbps, 10 devices ~ 14Mbps
Picking a couple of file sizes from my nas, which are in bytes, so x8 for bits.
Flac 16/44 is 35 MByte or 280 Mbit
Flac 26/48 is 57 MByte or 456 Mbit
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.
The 24/96 graph shows the speed the coordinator was retrieving the 456 Mbit long source. From Qobuz, or my NAS it loads as much of the data in as it can to fill the local buffer, then during playback if there is more data it keeps the buffer full until all of 456 Mbit Flac content is retrieved.
So with actual usable bandwidth of ~20 Mbps at the start of playback, the group coordinator was using up to ~15 Mbps to download, leaving only ~5 Mbps free to send the data to the group members during that time.
Once the download completes or the buffer fills the ~20 Mbps on the wifi can be used just to send data to the other members. When 5 seconds from the end of the track, the coordinator starts loading the next track. This doesn’t cause drop out if left to play. Most likely because the buffer in the group members is full enough it never empties during the burst to load the next track.
The group coordinator download speed appears to being limited by the device, because even changing from wifi to ethernet → sonosnet, the download speed into the group coordinator didn’t increase, but a larger number of group members could play.
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 …
… 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.
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.
Modern mesh Wi-Fi is fortunately backward compatible with the older legacy protocols, but that is at best a ‘patch’ for the bandwidth issues inherent to 802.11n.
...
One thing I’ve noticed on all my devices bar somewhat ironically the oldest Play:3 is that I get a large number of dropped packets on br0. Even on a relatively new Port which is ethernet connected with WiFi off… For example:
Now in general, everything seems to be ok, bar known functional limitations of the app, However, I don’t really understand why I’m getting so many dropped frames on all bar the Play:3? The Play:3 has actively been involved in groups with other speakers too, so isn’t used completely in isolation.
Does handling large amounts of dropped frames use more processing power? What’s ‘special’ about the Play:3 ?
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
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 …
… 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.
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.
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?
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…
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.
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
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.
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.
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
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.
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 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!
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
thank for sharing
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.
Thanks for that makes a lot of sense than firing lots of streams around if they can just grab it as it comes in. It also means it was coincidence of bandwidth usage with the different formats.
Curious that Apple only send ~3Mb/s which is more than enough rather than Qobuz pushing at it’s higher rate.
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
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.
Indeed, although my zp80 & 2 x zp100 when I first used Sonos are long gone. The zp80 and one of the zp100s died a slow hardware failure. The remaining one while still showing signs of life didn’t get used again.
The products I’m using are
2 x Symfonisk bookshelf gen 1 1 x Symfonisk bookshelf gen 2 3 x Symfonisk lamp gen 1 1 x Sonos Sub Mini
Of the above, the 2 x bookshelf gen 1 + sub were a stereo pair with sub. Regular usage pattern had them grouped with the bookshelf gen 2. My Qobuz account was setup for 24/48 for Sonos devices and never had an issue.
With a stereo + sub setup it is very noticeable when the right channel disappears even if the sub isn’t really contributing. It was used daily as they were on my desk working from home and used daily. Now just the bookshelf + sub setup becomes unstable changing streams, which previously never happened.
While the Symfonisk’s gen 1 were released 2019, that doesn’t provide a reflection of the board inside. Teardowns of both the bookshelf and lamp that I’ve seen suggest it is the same board that was in the Play One with the NXT chip. The chip itself is rev 4 of a system on a chip originally released in 2015.
With the pause in transition, does that occur on all speakers in the group? The behaviour exhibited with mine is that the group controller (receiving the stream) plays continuously and it is the group members or paired speaker+sub that are disrupted.
I don’t have an apple music subscription, although I could enable the trial they keep pushing
With the pause in transition, does that occur on all speakers in the group? The behaviour exhibited with mine is that the group controller (receiving the stream) plays continuously and it is the group members or paired speaker+sub that are disrupted.
Pause is to all speakers, as they are grouped and ‘listening’ to same stream. I know what speakers can support lossless, so I know if I add an older speaker to higher bit rate 48/24 stream, I may get a slight pause as it reconfigures to lower bit rate.
In an optimum configuration on your wireless network all grouped Sonos devices on same channel and AP, they will listen in to the unicast stream to the coordinator, ie in promiscuous mode. eg 4 Sonos devices on single channel on single AP, will be 3Mbs total bandwidth for lossless 48/24 stream on the AP, as its only one stream to a single IP address.
If you have multiple AP and/or additional 5Ghz etc, with more Sonos devices, then that is additional bandwidth to those devices.
I don’t have an apple music subscription, although I could enable the trial they keep pushing
If you are used to the new Sonos App UI, the Apple Music UI will be familiar/intuitive, and vis versa
I haven’t had much time for testing anything further this week but will be able to sit down properly this weekend and spend time looking further into it.
At the moment there are two ways to bring instability to my setup.
Increase the complexity of the audio, ie old 128Kbps mp3 → 24/48 streams either pushed from Qobuz or read from my NAS. I have the downloaded version of Jessie Ware’s album on my NAS along with the stereo audio tracks from my own concert DVDs. With Qobuz I can set the maximum format of the stream they send as 330Kbps mp3, 16/44.1 CD or 24/48
Increase the size of the group.
The bookshelf + sub setup as a stereo pair + sub had been faultless prior to upgrading and the content I’m playing is the same as before the upgrade.
The lamps have been mainly single playback background music, but I did find time to quickly turn 2 into a stereo pair + sub and they played back without disruption the same things the bookshelf + sub struggled with.
My plan for the weekend it to completely remove the speakers from my main network into their own network to remove any potential outside interference from the network they had always worked on.
Best case they just work as before and the update + my existing network don’t work well together anymore.
Worst case they exhibit the same behaviour
I am certain it isn’t controller/app related because the same behaviour occurs regardless of whether I use the Sonos App, Sonos Web player, SonoPad or the basic play/pause, next/previous controls of the Ikea Homesmart app.
At idle there are no issues with discovery, creating/disbanding stereo pairs, moving the sub around or the Sonos App, SonoPad or the Ikea Homesmart App reflecting those changes as they occur.
An brief observation on SonoPad, was that the track time progress would stop and with a larger group the playback queue would disappear until playback stabilised as though it couldn’t retrieve it from the coordinator. If I change tracks while the group is unstable, then occasionally group members would play part of the previous track before trying to switch streams as though the control messages were delayed.
Completely isolated I should also be able to bandwidth limit the rate of the Qobuz stream, which is currently far higher than needed just to stream 24/48.
I have no idea what the cpu demands are within the speakers, but as the stream format complexity increases, the rate of network traffic increases, the group gets larger, the cpu has more to deal. With the music library on my NAS, rather than having to deal with whatever Qobuz is pushing, it changes to the speaker pulling what it needs, so maybe that will have an influence.
