Skip to main content
Answered

Interesting read on how sonos is changing

 

https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc/

 

What happened to the Sonos app? A technical analysis

 

 

Andy Pennell

Principal Software Engineer at Xbox, Microsoft

 

July 6, 2024

On May 7th, 2024, Sonos, the successful home-audio company, released a new mobile app. This had been hyped in the press and was going to make product setup easier and greatly improve the user experience. However, when the app was actually released, it was, and somewhat remains, a disaster. As a certified Sonos fanboy/hacker/almost-employee I'm going to try and explain what happened, as best I can based on my reverse engineering skills, honed over the last decade and more of creating independent Sonos apps.

How The "Old" App Worked

Sonos speakers have been the Gold-standard UPnP device since their creation. I remember around 2005 the lobby to Microsoft Building 50, which was the home of the Windows Media Division at that time, was completely full of boxes of Sonos devices. It was being used as the definitive test device for the engineers adding UPnP support to Windows.

Every Sonos device on the network (which nowadays can be Ethernet, Wifi or SonosNet, their proprietary wireless network) exposes many UPnP services in the standard way, and can be found via the SSDP discovery process. There are around 200 individual APIs exposed via their UPnP services, though you can write a fully functional Sonos app using less than half of them. UPnP calls are SOAP calls over TCP, sending and receiving xml. SSDP works via UDP broadcast and multicast. All of this works very well, the common problems customers have with device discovery (changing IP addresses, inability to route between 2.4GHz/5GHz devices) are usually solved by fixing router settings or, occasionally, replacing a router with something better.

Sonos devices also use an interface known as SMAPI to communicate with third party music services. This standardization means that the onus on adding a music service to a Sonos system is on the music provider, which has allowed Sonos to support over a hundred music services, something no-one else has come close to. The app uses SMAPI to find and enumerate music from a provider, and the speakers themselves use SMAPI to stream the music and share with other speakers in their group in real-time.

The SMAPI interface is reasonably well documented (well, it was until last year), but the Sonos UPnP APIs have never been openly documented. Fortunately, UPnP is a self-describing interface so any decent tool can show you the APIs and let you experiment - I use Intel's UPnP Spy to do this. As traffic is in the clear, network traces can reveal exactly how the app uses these APIs to find and playback music.

A third API set for Sonos is their cloud API: this has been around for around five years, and is somewhat documented. However it's never been rich enough to write a decent app: it was designed for music service integrators (think Spotify Direct), not app creators. It offers basic transport control but no way of enumerating music, unless you are also a music service provider.

How The "New" App "Works"

For the new app, Sonos threw out all of the old app code, a "clean slate" approach, replacing the front-end (the UX everyone loves to hate) and also the back-end (that actually communicates with speakers and music services).

Device Discovery

When the app starts, it must find your speakers as a critical precursor to anything else, but for some inexplicable reason they decided to drop SSDP and rely entirely on mDNS for device discovery. I don't know much about mDNS (as my own Sonos apps have never used it), but evidently this new way of finding speakers on the network has proven hugely problematic. My reading of how mDNS works is that it should suffer from similar problems to SSDP on routers that can't broadcast/multicast between radios, but it shouldn't offer new problems. But evidently it does: the huge amount of users who had perfectly working systems that suddenly had no devices found in the app shows that either mDNS is not a reliable discovery system on many home networks, or their code has some gigantic flaws. Me? I'm fine, my carefully-configured Ubquiti network has never had a problem with the new app finding my 15 Sonos devices. Others have not been so lucky, and right now, two months after the new app's release, something still stinks in the Sonos device discovery code, based on Facebook and Reddit anecdotal data.

App Performance

The old S1 app, which I am very familiar with (details later), used the native UX frameworks of the devices, ported to each platform. So Windows used WPF and the other platforms used whatever the "normal" UX frameworks were at the time. This gave solid experiences on all platforms, but obviously at substantial cost: every new feature in the UX had to be implemented in four different UX codebases. (The back-end was C/C++ and shared between all of them). For the new app, Sonos decided to use the same front-end on both mobile platforms so went with a Javascript framework (I try not to follow JS-UX-frameworks-du-jour so can't say which) so the UX code would only need writing once. (The Windows/Mac apps have been feature-frozen since the S1 split so no chance of their UX changing). I'm not sure how much of a performance impact the UX framework has on the app (that's not an area I know too much about), but a change that has clearly had a notable impact on app performance is the back-end change, moving away from UPnP.

Network traffic with the new app is all encrypted, so a definitive analysis will take me a lot more work and time. However, my most educated guess based on what I see in the traces is that the speakers now expose a version of the Sonos cloud API, but on the local network. In addition eventing, which used to be UPnP based (essentially you run a simple http server in the app and it gets calls from the speakers when an event is sent) is now based on a websocket.

As all traffic is now encrypted, it takes more CPU cycles for every network call: client encrypts it, sends it (TLS is a lot more chatty), and the speakers have to decrypt it before they can do anything. Even if the API was still UPnP under the hood (which I don't think it is), the crypto overhead is going to be a challenge on the older Sonos devices, which have tiny amounts of RAM (as low as 64MB compared to 8GB of the latest Sonos devices) with a similar disparity in CPU power. Also the cloud API is more "chatty" than the UPnP API, multiplying the network overhead.

The best example of how bad this can be is the Device Volume UX: in a group of, say, 8 speakers, you can pop up the device volume panel, which will show all 8 device volumes, along with the Group volume. (Group volume is a weighted average of every device volume). Users like to drag volume sliders all over the place, but in a Sonos group this generates a cacophony of volume-changed events: changing the group volume will change the volume on every device, and every device will send an event back declaring its new volume. As many volume changes can be generated per second with a user's finger, and the fact that the event ordering is not guaranteed, it takes great care to get this UX smooth and responsive. This is the one area of my own Sonos apps that I fear the most: I never want to change any of the volume UX code. Sonos even publish recommendations on how to deal with this problem at https://docs.sonos.com/docs/volume. Seemingly they did not follow their own advice with the new app's volume control, and the switch from UPnP events to websockets seems to have made things a lot worse.

The New User Interface

I'm not going to rant about this too much, I know from decades in the business that you can't please all the people all the time, especially when it comes to UX. Also glass houses: my apps have not been renown for their glorious UX. However I have an iPhone SE 3 and that means I only get a tiny amount of vertical space in the new app to select music, plus I hate sliding UX as the iPhone likes to pop its system UX up when I do this. I always use my own app to select music anyway, I love the huge 4K display on my PC.

Can it get better?

Sonos have been mostly in denial as to how bad things are, with the app release officially described as "courageous" - well, pissing off a sizable chunk of your existing user base could be called that, I guess. An immediate revert to the old version would have been my suggestion.

Also thanks to the device discovery problems, not only are existing users frustrated with the app not working, but new users who get their shiny Sonos device out of the box and then can't get the app to work are just going to put it back in the box and return it.

The new app shipped with a lot of features missing from the old app (never a good idea), but over the last two months some of those features have returned in various updates. However Queue management is still AWOL, and that was a key Sonos feature. (It's also a UX challenge, handling a list of over 30,000 items that can change at any time in a performant way).

While device discovery remains a crapshoot for many the app store scores are likely to stay in the 1.0 range that they have fallen to in the last two months.

Options

As many have discovered, the Sonos speakers themselves are still working fine, despite the contrary impression the new mobile apps may give. You can verify this by using the official Desktop apps (which are feature-frozen), or third party software like SonoPhone (for iOS https://apps.apple.com/us/app/sonophone-for-sonos/id815251931) or my own Phonos Universal (for Windows/Xbox https://apps.microsoft.com/detail/9nblggh4x6j0). All of these apps use the UPnP APIs, which still work great, for the moment anyway. However, Sonos have stated that they want to deprecate their desktop apps at some unspecific point in the future. If they do, they can then remove UPnP support from the speakers, killing the entire third-party ecosystem built around their products. That would be "courageous" indeed.

About Me

I've been a Sonos customer since the CR100/ZP100 released and been reverse engineering it since shortly after it arrived. My Sonos app for Windows Phone was one of the most successful employee-made paid apps in the store and had over 200,000 downloads. I worked with Sonos on Phish, the official Sonos app for Windows Phone 8 (never released). I was so impressed with Sonos engineering I applied for a job there and got an offer to join their Seattle office, but I declined, because reasons. I live in NetMon.

Views expressed here are my own, and not those of my employer, Microsoft Corp.

92 replies

sigh
Userlevel 6
Badge +8

Sonos has loyal, but somewhat older and somewhat complacent user base. Rich enough to buy speakers and having the space and housing to place them around but not willing to invest in becoming “tech savvy” as some of them call using a manual.

They share the last point with a new set of users, but not the first points. My kids only use headphones/Airpods with their phones. The Sonos speakers in their rooms do not get any use - only the bathroom speaker is used by them. When they move out there first housing will be shared and so the headphones will still be used. I do not see them buy any speakers or having the housing to place speakers. I think Sonos saw this demographic to and it scared the living daylights out of them.

I can see the move by Sonos to the headphones and more web based orientation. I still disagree with how they handled the introduction of the new app and the missing consideration they gave to their current user base. It seems the move to the cloud does not go lightly with a large percentage of the current users whose networks are not perfect.

Introducing the app in an unfinished state and dropping http and SMBv1 access to music libraries at almost the same time as introducing the new app only compounded the problem, again forgetting the current user base.

It’s an interesting perspective, but from my view point your description of the young doesn’t sound any different to my experience as a teenager.

Back then I wouldn’t leave the house without my Aiwa Walkman/Radio and headphones. When I moved out of home to the opposite end of the country, I was sharing a house and while I went to Richer Sounds to get an integrated amp + speakers, one of my housemates just used a clock radio and the other had headphones permanently in his ears.

My working life from ~2004 onwards I’ve always been environments with a mixture of people wearing headphone and not. Back then it was a mix of Archos, Cowen, Creative and iPods in use until Spotify appeared and some found the music they liked could just be streamed instead.

My own son isn’t really any different to I was. He takes his phone and streams instead of a Walkman when he leaves the house, but otherwise it’s no different. In the house I think there have been 2 main influences. A mix of both age/interest, he and his friends play games and build virtual worlds online so use headphones for chatting and playing online. Additionally in recent years the pandemic lockdowns, meant an increase in headphone usage for everyone in the house due to online lessons, confidential work conversations and wanting to block out other general background noise.

 

My personal aversion to unnecessary cloud dependency comes from most of my working life being on the other side of the curtain. Most of it has been spent designing, building and supporting large scale online platforms. The majority of companies either operated in highly regulated environments and/or with sensitive data, so questioning do we actually need this data or dependency has been a significant question throughout my working life. The companies had no problem refusing to collect or create unnecessary dependencies regardless of the size of the client requesting as we would be on the hook for any issues, fines or worse, not the client requesting it.

 

I don’t think the headphone demographic is what scares Sonos, if it did the USP of the Ace wouldn’t require an expensive soundbar and they wouldn’t be so expensive. Sonos used to be in a unique position, their products sat above the cheap mass market mini music systems and boom boxes, but below the HiFi separates market in quality with the premium providing a just works product for local playback and the emerging streaming market.

Now they are the in the difficult position where they are losing their USP. The traditional split of audio companies, video companies and IT companies has gone.

On the one hand, Amazon and Apple are both content providers and with the surprising success of the cheap voice assistant speakers are now taking a segment of the audio and video market seriously. Google will continue to be as random as ever but own the 5th largest audio streaming service globally.

Advances in microchips and audio chips provide a low cost of entry into device manufacture with devices that are good enough for the mass market. Companies who previously had little interest in audio or were unknown outside their home market, such as Samsung, HiSense amongst others are expanding into everything and often have pockets deep enough to buy companies rather than need to start from nothing and develop everything themselves.

The way music is accessed and the devices used for playback have changed and been embraced by the mass market. I suspect far faster than many companies expected and for those caught unawares, new upstarts and far larger companies saw and moved on opportunities.

P
Userlevel 5
Badge +7

Why can’t sonos let us run webb app on safari browser, it fails something about wrong screen size formatting or similar

I only have pc at work

On my Mac, I’m running Safari v17.5 (17618.2.12.111.5, 17618) and the web app is working fine here. 
What screen resolution do you have your Mac display set to?

i was trying to use it on iphone


On iPhone I’ve done this:

  1. Using Safari, login at play.sonos.com and save login info to iCloud

  2. Once the page opens, tap Aa on address bar and from menu select Website Settings >  Request Desktop Website. Tap Done.  (This will load that website as the required desktop version in the future.)

  3. Tap on Share icon and tap Add to Home Screen. Give the icon a name. 

  4. Start controlling Sonos using that Home Screen icon. (It remembers the session quite long but log in again if asked, Safari should ask whether to use the stored login info.) 

Turn iPhone landscape to see a better view. 

On iPad, it’s been enough to add the website via the Share > Add to Home Screen. The page layout is fine as is. 
 

The key is the desktop website view and Safari allows to define that setting by website unlike Chrome which has a global setting.

 

This works a treat, thanks

i jumped turn phone landscape at first 😁

Sonos could maybe suggest this to help users diagnose

Musicasa
Userlevel 1

 

https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc/

 

What happened to the Sonos app? A technical analysis

 

 

Andy Pennell

Principal Software Engineer at Xbox, Microsoft

 

July 6, 2024

On May 7th, 2024, Sonos, the successful home-audio company, released a new mobile app. This had been hyped in the press and was going to make product setup easier and greatly improve the user experience. However, when the app was actually released, it was, and somewhat remains, a disaster. As a certified Sonos fanboy/hacker/almost-employee I'm going to try and explain what happened, as best I can based on my reverse engineering skills, honed over the last decade and more of creating independent Sonos apps.

How The "Old" App Worked

Sonos speakers have been the Gold-standard UPnP device since their creation. I remember around 2005 the lobby to Microsoft Building 50, which was the home of the Windows Media Division at that time, was completely full of boxes of Sonos devices. It was being used as the definitive test device for the engineers adding UPnP support to Windows.

Every Sonos device on the network (which nowadays can be Ethernet, Wifi or SonosNet, their proprietary wireless network) exposes many UPnP services in the standard way, and can be found via the SSDP discovery process. There are around 200 individual APIs exposed via their UPnP services, though you can write a fully functional Sonos app using less than half of them. UPnP calls are SOAP calls over TCP, sending and receiving xml. SSDP works via UDP broadcast and multicast. All of this works very well, the common problems customers have with device discovery (changing IP addresses, inability to route between 2.4GHz/5GHz devices) are usually solved by fixing router settings or, occasionally, replacing a router with something better.

Sonos devices also use an interface known as SMAPI to communicate with third party music services. This standardization means that the onus on adding a music service to a Sonos system is on the music provider, which has allowed Sonos to support over a hundred music services, something no-one else has come close to. The app uses SMAPI to find and enumerate music from a provider, and the speakers themselves use SMAPI to stream the music and share with other speakers in their group in real-time.

The SMAPI interface is reasonably well documented (well, it was until last year), but the Sonos UPnP APIs have never been openly documented. Fortunately, UPnP is a self-describing interface so any decent tool can show you the APIs and let you experiment - I use Intel's UPnP Spy to do this. As traffic is in the clear, network traces can reveal exactly how the app uses these APIs to find and playback music.

A third API set for Sonos is their cloud API: this has been around for around five years, and is somewhat documented. However it's never been rich enough to write a decent app: it was designed for music service integrators (think Spotify Direct), not app creators. It offers basic transport control but no way of enumerating music, unless you are also a music service provider.

How The "New" App "Works"

For the new app, Sonos threw out all of the old app code, a "clean slate" approach, replacing the front-end (the UX everyone loves to hate) and also the back-end (that actually communicates with speakers and music services).

Device Discovery

When the app starts, it must find your speakers as a critical precursor to anything else, but for some inexplicable reason they decided to drop SSDP and rely entirely on mDNS for device discovery. I don't know much about mDNS (as my own Sonos apps have never used it), but evidently this new way of finding speakers on the network has proven hugely problematic. My reading of how mDNS works is that it should suffer from similar problems to SSDP on routers that can't broadcast/multicast between radios, but it shouldn't offer new problems. But evidently it does: the huge amount of users who had perfectly working systems that suddenly had no devices found in the app shows that either mDNS is not a reliable discovery system on many home networks, or their code has some gigantic flaws. Me? I'm fine, my carefully-configured Ubquiti network has never had a problem with the new app finding my 15 Sonos devices. Others have not been so lucky, and right now, two months after the new app's release, something still stinks in the Sonos device discovery code, based on Facebook and Reddit anecdotal data.

App Performance

The old S1 app, which I am very familiar with (details later), used the native UX frameworks of the devices, ported to each platform. So Windows used WPF and the other platforms used whatever the "normal" UX frameworks were at the time. This gave solid experiences on all platforms, but obviously at substantial cost: every new feature in the UX had to be implemented in four different UX codebases. (The back-end was C/C++ and shared between all of them). For the new app, Sonos decided to use the same front-end on both mobile platforms so went with a Javascript framework (I try not to follow JS-UX-frameworks-du-jour so can't say which) so the UX code would only need writing once. (The Windows/Mac apps have been feature-frozen since the S1 split so no chance of their UX changing). I'm not sure how much of a performance impact the UX framework has on the app (that's not an area I know too much about), but a change that has clearly had a notable impact on app performance is the back-end change, moving away from UPnP.

Network traffic with the new app is all encrypted, so a definitive analysis will take me a lot more work and time. However, my most educated guess based on what I see in the traces is that the speakers now expose a version of the Sonos cloud API, but on the local network. In addition eventing, which used to be UPnP based (essentially you run a simple http server in the app and it gets calls from the speakers when an event is sent) is now based on a websocket.

As all traffic is now encrypted, it takes more CPU cycles for every network call: client encrypts it, sends it (TLS is a lot more chatty), and the speakers have to decrypt it before they can do anything. Even if the API was still UPnP under the hood (which I don't think it is), the crypto overhead is going to be a challenge on the older Sonos devices, which have tiny amounts of RAM (as low as 64MB compared to 8GB of the latest Sonos devices) with a similar disparity in CPU power. Also the cloud API is more "chatty" than the UPnP API, multiplying the network overhead.

The best example of how bad this can be is the Device Volume UX: in a group of, say, 8 speakers, you can pop up the device volume panel, which will show all 8 device volumes, along with the Group volume. (Group volume is a weighted average of every device volume). Users like to drag volume sliders all over the place, but in a Sonos group this generates a cacophony of volume-changed events: changing the group volume will change the volume on every device, and every device will send an event back declaring its new volume. As many volume changes can be generated per second with a user's finger, and the fact that the event ordering is not guaranteed, it takes great care to get this UX smooth and responsive. This is the one area of my own Sonos apps that I fear the most: I never want to change any of the volume UX code. Sonos even publish recommendations on how to deal with this problem at https://docs.sonos.com/docs/volume. Seemingly they did not follow their own advice with the new app's volume control, and the switch from UPnP events to websockets seems to have made things a lot worse.

The New User Interface

I'm not going to rant about this too much, I know from decades in the business that you can't please all the people all the time, especially when it comes to UX. Also glass houses: my apps have not been renown for their glorious UX. However I have an iPhone SE 3 and that means I only get a tiny amount of vertical space in the new app to select music, plus I hate sliding UX as the iPhone likes to pop its system UX up when I do this. I always use my own app to select music anyway, I love the huge 4K display on my PC.

Can it get better?

Sonos have been mostly in denial as to how bad things are, with the app release officially described as "courageous" - well, pissing off a sizable chunk of your existing user base could be called that, I guess. An immediate revert to the old version would have been my suggestion.

Also thanks to the device discovery problems, not only are existing users frustrated with the app not working, but new users who get their shiny Sonos device out of the box and then can't get the app to work are just going to put it back in the box and return it.

The new app shipped with a lot of features missing from the old app (never a good idea), but over the last two months some of those features have returned in various updates. However Queue management is still AWOL, and that was a key Sonos feature. (It's also a UX challenge, handling a list of over 30,000 items that can change at any time in a performant way).

While device discovery remains a crapshoot for many the app store scores are likely to stay in the 1.0 range that they have fallen to in the last two months.

Options

As many have discovered, the Sonos speakers themselves are still working fine, despite the contrary impression the new mobile apps may give. You can verify this by using the official Desktop apps (which are feature-frozen), or third party software like SonoPhone (for iOS https://apps.apple.com/us/app/sonophone-for-sonos/id815251931) or my own Phonos Universal (for Windows/Xbox https://apps.microsoft.com/detail/9nblggh4x6j0). All of these apps use the UPnP APIs, which still work great, for the moment anyway. However, Sonos have stated that they want to deprecate their desktop apps at some unspecific point in the future. If they do, they can then remove UPnP support from the speakers, killing the entire third-party ecosystem built around their products. That would be "courageous" indeed.

About Me

I've been a Sonos customer since the CR100/ZP100 released and been reverse engineering it since shortly after it arrived. My Sonos app for Windows Phone was one of the most successful employee-made paid apps in the store and had over 200,000 downloads. I worked with Sonos on Phish, the official Sonos app for Windows Phone 8 (never released). I was so impressed with Sonos engineering I applied for a job there and got an offer to join their Seattle office, but I declined, because reasons. I live in NetMon.

Views expressed here are my own, and not those of my employer, Microsoft Corp.

Thank you for sharing Andy’s summary analysis. I wrote the Sonos CEO yesterday. I’m pasting his response here:

Sonos Support
Fri, Jul 19, 8:00 PM (16 hours ago)
to me


Hello and thank you for taking the time to reach out to me.


I’ve received a great deal of feedback regarding our new app, on both the improvements made, as well as where we fell short. If you are among those for whom the experience is falling short, I want you to know that I hear you. Teams across Sonos are working diligently to address customer concerns as quickly as possible. 


Since launch, we have reintroduced a number of features via updates, including the ability to add and edit alarms, sleep timer settings, add songs to the queue and play next, as well as initial screen reader improvements for iOS VoiceOver that will allow users to more easily navigate the app. We continue to roll out updates regularly, so please ensure your Sonos App and products are all up to date: https://support.sonos.com/article/update-your-sonos-speakers 


Over the coming weeks, we will reintroduce local music library search and playback, as well as Update Wi-Fi settings, at the same time that we continue to address bugs and performance issues.


In the meantime, if you are experiencing an issue with your Sonos System, you may find the following resources helpful, and are always welcome to reach out to our support team directly.


Sonos Community

Sonos App User Guide

Sonos Support Home

Sonos Support Contact

 

Thank you again for being a Sonos customer, and for taking the time to reach out to us to share your feedback. I, and the full team at Sonos are committed to delivering on a Sonos experience that brings the joy of unparalleled sound into your lives every day. Delivering on our promise of an easier, faster and better app experience is fundamental to this aim, and you have my personal word that nothing is more important to us at this time.

Sincerely,

Patrick Spence

 

https://en.community.sonos.com/ask-a-question-228987/interesting-read-on-how-sonos-is-changing-6899414?postid=16768407#post16768407

P
Userlevel 5
Badge +7

That's standard spiel auto response, seem it many times unfortunately

I do believe support staff are working tirelessly, they have to learn new app faults as well from feedback

Musicasa
Userlevel 1

Yup, boiler plate canned response. 

I
Userlevel 6
Badge +10

So does the new use of mDNS which would effectively appear to be labelled as Bonjour on lots of network kit, mean that as well as all the detailed steps to get STP config right on managed switches, you now (ideally) need a switch that supports mDNS/Bonjour, and that these settings are correctly configured to allow the packets to get where they need to? 

I do have a little sympathy with Sonos here (less with the new app) as there are too many devices ‘trying’ to make this stuff invisible that then trip over each other. For example, Sky Q devices attempt to create a mesh WiFi whether you want it or not, and as such advertise STP bridge IDs below those used by Sonos… If you want to get control of your network back then you need a ‘proper’ managed switch, which now it seems needs to hande mDNS too… I say proper as some of the cheaper managed switches have very limited options. 

Is this level of complication the only way to get the ‘Sonos sync’ to function or could it be done over a vanilla network without using STP etc? 

sigh
Userlevel 6
Badge +8

So does the new use of mDNS which would effectively appear to be labelled as Bonjour on lots of network kit, mean that as well as all the detailed steps to get STP config right on managed switches, you now (ideally) need a switch that supports mDNS/Bonjour, and that these settings are correctly configured to allow the packets to get where they need to? 

I do have a little sympathy with Sonos here (less with the new app) as there are too many devices ‘trying’ to make this stuff invisible that then trip over each other. For example, Sky Q devices attempt to create a mesh WiFi whether you want it or not, and as such advertise STP bridge IDs below those used by Sonos… If you want to get control of your network back then you need a ‘proper’ managed switch, which now it seems needs to hande mDNS too… I say proper as some of the cheaper managed switches have very limited options. 

Is this level of complication the only way to get the ‘Sonos sync’ to function or could it be done over a vanilla network without using STP etc? 

No, not at all. multicast DNS (mDNS) operates within the multicast IP range on 224.0.0.251/ff02::fb port 5353.

It has no requirement for a managed switch, but if you are using one with igmp enabled, that should cover it. As it is designed for local-link network, if you use vlans and want to cross the vlan boundary then you will need a reflector/repeater rather than using an igmp proxy.

A badly configured mDNS client can have some unexpected behaviour and both Linux distribution maintains and the System-D development team have been caught out in the past.

for example, mDNS has the .local domain reserved for it’s use and no requirement for a dns server on the network. an mDNS client should ignore any unicast response from a standard DNS server on the LAN claiming to be authoritative for the .local domain and only use responses for the .local domain from the multicast IP address.

If you don’t ignore the .local response from the LAN DNS server then odd things can occur with discovery.

 

The Sonos STP can of worms is completely unrelated to mDNS and really shouldn’t still be a thing. As far as I’m aware they haven’t updated to RSTP, so in managed switches where you can’t disable STP on the ports Sonos is attached to, you have no option but to configure it for Sonos settings. On my own switches pretty much ignored the Sonos STP, left STP disabled in my switches and enabled RSTP. Sonos did it’s thing, while all my other devices did theirs without any issues. 😂

controlav
Userlevel 7
Badge +23

No, not at all. multicast DNS (mDNS) operates within the multicast IP range on 224.0.0.251/ff02::fb port 5353.

It has no requirement for a managed switch, but if you are using one with igmp enabled, that should cover it. As it is designed for local-link network, if you use vlans and want to cross the vlan boundary then you will need a reflector/repeater rather than using an igmp proxy.

A badly configured mDNS client can have some unexpected behaviour and both Linux distribution maintains and the System-D development team have been caught out in the past.

for example, mDNS has the .local domain reserved for it’s use and no requirement for a dns server on the network. an mDNS client should ignore any unicast response from a standard DNS server on the LAN claiming to be authoritative for the .local domain and only use responses for the .local domain from the multicast IP address.

If you don’t ignore the .local response from the LAN DNS server then odd things can occur with discovery.

So @sigh you clearly know a lot more about mDNS than I (as I admitted in my article), so do you think the discovery problems are caused by crappy router implementations, or a crappy implementation in the Sonos app? (Or both??). Or even a crappy implementation in another device on the network??

Author of the leading independent Sonos app for Windows, the only Sonos app for Xbox, and a Sonos app for iOS
jnelly
Userlevel 3
Badge +4

This was a great technical explanation of how @SONOS works, that a layperson could follow. Thanks for posting @sigh!

I’m going to try the Sonophone app. I don’t like the newS2 UI, especially for using music apps. You have to scroll several pages to get back to TV or other things, and SonosRadio and TuneIn still don’t work in newS2, lol.

 

Sonos Radio and the TuneIn app work in SonoPhone. Sheesh, SonoPhone ($3.99) hooked up immediately, I didn’t have to log in or anything. No deep controls or eq, that I can see. The newS2 also updates and saves my SonoPhone activity, at least some of it, upon cursory use, in newS2!

Great suggestion @106rallye!!!!

C
Userlevel 6
Badge +12

No, not at all. multicast DNS (mDNS) operates within the multicast IP range on 224.0.0.251/ff02::fb port 5353.

It has no requirement for a managed switch, but if you are using one with igmp enabled, that should cover it. As it is designed for local-link network, if you use vlans and want to cross the vlan boundary then you will need a reflector/repeater rather than using an igmp proxy.

A badly configured mDNS client can have some unexpected behaviour and both Linux distribution maintains and the System-D development team have been caught out in the past.

for example, mDNS has the .local domain reserved for it’s use and no requirement for a dns server on the network. an mDNS client should ignore any unicast response from a standard DNS server on the LAN claiming to be authoritative for the .local domain and only use responses for the .local domain from the multicast IP address.

If you don’t ignore the .local response from the LAN DNS server then odd things can occur with discovery.

So @sigh you clearly know a lot more about mDNS than I (as I admitted in my article), so do you think the discovery problems are caused by crappy router implementations, or a crappy implementation in the Sonos app? (Or both??). Or even a crappy implementation in another device on the network??

I don’t like the word crappy, I prefer misconfigured 😀

mDNS should work fine on a simple modern consumer network. Its used in many consumer devices, such as printers, cameras, AirPlay, etc. When it can get messy is when ‘prosumer’ or ‘enterprise’ network devices are used in a consumer network environment, and have not been configured correctly by the installer. @sigh  makes a good point .local was a Microsoft? default for local DNS TLD about 20 years ago, if this is still used in a consumer network, it could potentially cause issues.

Sonos could (have?) code their software to use alternative method for discovery if mDNS is not discovering as expected. The speakers could (in theory) ‘phone home’ with discovery details, and the App could get the details from a remote service, and cache them locally?

 

sigh
Userlevel 6
Badge +8

If someone had no discovery issues with the old app, but is having them with the new app, my gut feeling is that it is in the app side, but not necessarily that mDNS is failing.

How and where the app is handling the overarching discovery process and dealing with responses from the local mDNS discovery and the api.ws.sonos.com request could be what is causing issues, rather than the local mDNS.

The old app had 2 different behaviours depending whether you were logged into your Sonos account. Opening the app from closed to the System page

When not logged in to the sonos account in the app:

  • it performs local discovery and shows the Sonos devices that respond

When starting the app and logged into your sonos account 3 things happen in parallel:

The responsiveness and what devices are shown with the logged in behaviour of the old app can be influenced by external issues when attempting to connect to the Sonos api during device discovery.

Blocking *.sonos.com with a pi-hole or similar, then the discovery behaves similar to not being logged is just slightly slower because the pi-hole returns a NULL response to the api dns request which causes the app to give up the connection attempt and show the list of devices which responded locally.

A slow request to the Sonos api, which could be anything from slow dns responses, overloaded internet connection, overloaded sonos servers, random other event somewhere on the internet, causes the app to keep showing grey placeholders until a timeout out is hit.
When the timeout is hit it flashes an issue finding devices notification, then immediately displays all the locally found devices only. When the request eventually completes, or retries later, additional devices registered against the sonos household but not found through local discovery get added to the list.

I simulated the above by overloading my pi-hole before starting the app. When the api call had reached a timeout (~10 sec I think) during discovery, it flashed an error notification, showed my 4 locally switched on speakers. When the pi-hole recovered before the usual default 30 second dns timeout a call completed and 3 speakers which have been unplugged for about a month, but still registered with my account, showed up as unavailable.

 

Where it becomes tricky to identify what might actually be causing it, is that things have moved around in the new app. eg login in is now a requirement, the app doesn’t auto switch households based on local discovery, the new local search currently happens in a process which requires working internet (to be separated in a future update)

While the discovery process may be similar, eg perform local discovery and call the api in parallel, it is likely wrapped in a different overarching app flow.
How that reacts if there is an issue, such as the online call times out and/or has no response does it show nothing? What happens if there is a mismatch between locally discovered but registered devices and devices registered against the login account?

Ideally the behaviour would be the same as the old app, but given the changes in making things like login mandatory, other things like the recently added Local Library search currently only work with an internet connection (to be fixed in the future) it wouldn’t be a surprise to find device discovery and display of devices has ended up shackled to online requests which don’t react well to unexpected behaviour.


Something I found interesting about Airplay and the Apple TV is while it is still using bonjour as the primary discovery method, Apple have supplemented the bonjour discovery with Bluetooth LE discovery which sends out the Apple TV lan IP address. Over the many years they’ve been doing Airplay, maybe they found that adding the additional bluetooth discovery mechanism helped avoid issues in complex network setups, eg offices, and reduce home user issues due to random equipment either supplied by an ISP or it was the cheapest/store/online recommended item.

 

M

I had issues with Sonos pre new app release. I spent a bit of time looking at mDNS on my network (BT mesh WiFi) and concluded that there was a rate limit of broadcast (multicast and broadcast are treated the same on a WiFi network) traffic that could be triggered if there was enough of it. 
Broadcasts on WiFi network are sent at the lowest possible speed/max error correction to maximise the probability of all attached devices receiving the traffic as there’s no reliable method for ensuring delivery. As SSDP and mDNS/bonjour protocols use multicast (and will likely be treated as broadcast on most home routers) and as you add more and more smart devices the likelihood of this happening increase. 
My local network performance in terms of user experience of Sonos/homekit devices became worse and worse, even though my internet connectivity was stable, so I swapped out the BT mesh WiFi for an eero’s mesh and everything just started working. I’ve seen a few firmware updates on eero related to multicast and ssdp improvements so my guess is that there’s protocol inspection occurring that increases the broadcast limits for these traffic types. 
I’ve not personally had any issues with Sonos device discovery since the new app/firmware but I have experienced odd behaviours with grouping and loss of playback control using the Sonos controller. I’ve not had any issues using airplay. 
From the analysis done on this post it appears there has been a massive increase in broadcast traffic from Sonos so maybe the issues are twofold. 
One, the app stability, two, a step change in the number of customers triggering broadcast limits. 

S
Userlevel 6
Badge +2

Great post! thanks indeed.

I have a question about SonoPhone, can it completely replace the previous version of the S2 app? For example, link to other music apps, set alarms, etc., thank you.

 

I took the plunge today so I could perform some semblance of local Sonos control with my iPhone. The app’s UI is very dated and always seems to show one speaker at a time. It seems to work well for playing music (local and streaming). But as you ask, there don’t seem to be any Sonos management functions for Sonos in the app--notably alarms. Someone please correct me if these features exist.

buzz

Only the SONOS built controllers can configure the system. 3rd party controllers can only play music. Check the SonoPhone documentation because there are some options that popup if you touch longer.

R
Userlevel 7
Badge +15

Great post! thanks indeed.

I have a question about SonoPhone, can it completely replace the previous version of the S2 app? For example, link to other music apps, set alarms, etc., thank you.

 

I took the plunge today so I could perform some semblance of local Sonos control with my iPhone. The app’s UI is very dated and always seems to show one speaker at a time. It seems to work well for playing music (local and streaming). But as you ask, there don’t seem to be any Sonos management functions for Sonos in the app--notably alarms. Someone please correct me if these features exist.

Drag up the now playing area at the bottom of the screen to see all your speakers. Or tap the name of your system, top left on the Home Screen - that does the same thing.

Simply tap the speaker you want to play on, select the music, and away you go.

Also: Settings - Manage. That’s where you’ll find all the management functions, including alarms.

S
Userlevel 6
Badge +2

@Rhonny We are not talking about the Sonos app.

R
Userlevel 7
Badge +15

@Rhonny We are not talking about the Sonos app.

Apologies. Misread!

Reply


Terms & ConditionsCookie settings