Andy Pennell
Published Jul 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.
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.
