What happened to the Sonos app? A technical analysis

SUPER post @paulrw, that article connects a lot of dots for me!

Hopefully sonos mods won’t take it down…...

The article we have all be waiting for to understand better the root causes of the issues. Looks like it’s a combination of things, but largely a device discovery issue. 

Thanks for finding and posting this, @paulrw .

Hence why sonophone app Ios has helped alot of people in the interim of a fix

Very useful technical explanation. More than a couple questionable or bad choices discussed. Would like to see the insider discussion of the business decisions made.

Really interesting, eh @Rhonny? While I was aware of the switch to mDNS, the article adds a color on why that is problematic. Users experiencing ‘missing’ devices may have an exception or corner case that it is not handled by the new code (in the app and in the firmware) properly.

These two aspects are most interesting to me and I suspect are most problematic …

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.

e...]

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.

… the entire communication protocol between the mobile apps and devices changed. As the author notes, the ‘old’ protocol is still supported: this explains why many ‘gotchas’ encountered with the new mobile apps are ‘fixed’ with the desktop apps.

The big takeaway is that there is a lot more brand new code in the device firmware that I imagined: websockets, TLS, and Cloud API. All that new code works well when everything is “on the straight and narrow” but does not handle exceptions and corner cases. This fits what we’ve learned on these forums: “it works here” for many users and does not work for other users. Subtle underlying factors manifest themselves as broken functionality. The good(ish) news is that over time those exceptions and corner cases will (hopefully) be discovered-and-debugged-and-fixed by Sonos. The bad(ish) news is that process will take quite some time.

This is @controlav ’s article FYI. If you check r/Sonos the article has sparked quite a lot of (good) discussion if you are interested. 
 

Interesting and helpful information. Thank you for posting. Now, why wouldn’t Sonos just give us a brief explanation similar to that write up in the interest of transparency and accountability?

Do we just not do that anymore in business?

Despite having issues with my system I at least have more tolerance now after reading and better understanding some of these technical pieces behind all of it.

For every person who gains tolerance, you’d have 100 people saying “Who cares??? Just make it work!!!” or “Don’t try to BS us with technical jargon!!! It’s a f*&^ing music system!!!”

I think one of the biggest questions for me is how on earth did no-one in their technical development team flag that dropping SSDP for mDNS (plus those other elements in the article, flagged by @press250 ) might lead to device discovery issues and other such functionality fails?? Surely this would have then presented itself as a problem within the first weeks of development?

And upon implementation, when it was loosely Beta tested (and used by the CEO ‘since Christmas’?), we know that issues were flagged by those using the new app - so how did the issues being so widely discovered not throw up massive red flags and alarm sirens so as to put the brakes on its roll-out - even with the headphones to be launched and the financial results to be announced??

I’ve been (annoyingly, probably) measured in my call for patience in allowing Sonos to fix this (and my system works perfectly well with a well-tuned router and mesh setup) - but reading what appears to have been at the heart of these last two months of hell for some….REALLY SONOS???? 

Never underestimate the power of believing your own sales pitch and making wrong decisions for "business" reasons.

I hope this doesn’t sound too critical: testing is not a Sonos core competency. I'll be the first to acknowledge that testing anything that involves the cornucopia that is home Wi-Fi is super, super hard. I worked with one of the largest home networking companies, and in addition to all manner of extensive setups in their labs, they literally had their own house on an acre of property outfitted to the rafters with gear to test a universe of Wi-Fi scenarios. Microwave ovens that turned on an off to generate interference, laptop computers on rotating turntables to vary signal strength, and on and on and on.

So to answer your question @Rhonny, if your testing consists of one Wi-Fi network with an assortment of Sonos devices you will never discover 99% of potential pitfalls.

Which is why Sonos has Beta (and Alpha!) testers - many hundreds minimum.  To be successful, Sonos NEEDS to work in your typical house - not just in nigh on perfect environments owned and administered by network/IT experts/hobbyists.

However, ignore those testers at your peril - as evidenced by the dreadful experiences had by many over the last few months.

It’s quite ironic that many users have only been able to control their systems - or indeed, set them up using legacy Desktop apps or third party ones.

Will you people please stop harping on testing?  It was tested.  It failed.  It was released anyway.  This disaster has nothing to do with testing, development, or even IT in general.  It was about pleasing investors by getting the headphones launched, and when you depend on venture capital to survive, investors come first, second, third, and all the way up to next to last. Last are the customers.

They’ve committed to improving their VoiceOver beta user group back during the AMA. Hopefully they also expand the general beta group beyond Patrick Spence and the C suit and include some people who own more than Eras and Arcs or they’ll never fix the volume issue  

I have just updated the article copied above to add notes about the web app and improve the accuracy of some API speculation.

Fantastic article, @controlav, kudos! It connected a lot of dots and crystallized my thinking.

i was wondering if the web app was part of the motivation for the move to the Cloud API, so I appreciate your latest additions to the article. 

All of the rocket scientists have weighed in on the Sonos situation; but still no satisfactory resolution; no acknowledgment from Sonos management of the serious problems many users face; and no commitment from Sonos to address and resolve those problems by a date certain in the foreseeable future.

It begins to appear my best option might be to use the ‘line in’ feature on my newer Sonos speakers, lay hands on a cd player, turntable and preamp; and revert to using the library of CDs and LPs tucked away in my home. 

That assumes the Sonos speakers would work reliably as active speakers using external inputs. And that also pretty much defeats the reason I became a Sonos buyer — straightforward ‘plug and play’ access to digital music sources; the ability to find and save digital music in my own library of Sonos playlists; and pretty decent sound quality.

Were I setting up a CD/LP/amp/speakers system today, I most likely would not choose Sonos, as there are far better speaker systems and amps with streaming capability available for not a lot more money. The user friendly/convenience factor rates high in the choice to use Sonos speakers. Take that away and Sonos doesn’t have all that much to offer.

If Sonos management does not acknowledge that fact, I fear its hardware will become as obsolete as the eight-track cassette deck, which will be a tragic outcome for Sonos investors, employees and purchasers. 

And which readily could be avoided if Sonos would cease doubling down on its mistakes; allow users to revert to the pre-existing and reliable controller app; and refrain from re-releasing the ‘courageous’ new app until it has been adequately tested and proven reliable and fully functional.

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.

While we have a number of tech types assembled here, a question… although this falls under the heading ‘sweating the small stuff when the big stuff still doesn’t work.’

When I pull together a queue of tracks from numerous albums, from different streaming services, recorded at different times and venues, the recording levels can be all over the place. I wind up cranking the volume to achieve a desired listening level on track A, then have to ratchet volume down when track B comes up, blaring way too loud.

I’ve often wondered why the Sonos app did not have a feature to normalize volume level to smooth out these wide variations in recording level.

I have no idea whether that’s feasible or not… anyone here know if it could be done?

I’ve been wanting volume normalisation for years. I’m fairly sure I remember reading it wasn’t as easy as it seems because the speakers just play the tracks as provided by the streaming services, which are provided with a variation in level. The speakers can change the dynamics of the track through the EQ/Trueplay (a bit like a shower heating the water on the way through) but unlike the streamers’ own apps, the speakers can’t analyse the track’s level to raise or lower it for consistency (by the same analogy perhaps, it can’t change how wet the water is when it comes into the house from the water company)…

Or something like that. 

No, like other third party apps, setup-level operations (eg add music service, update firmware, add devices) are not supported.

I don’t think SonoPhone can do Alarms, but my Windows app can.

Great article, which has really helped me appreciate that I’m probably having such exterme problems because a) my router setup just uses BT’s own device with extenders (and is probably not man enough for the job in hand) and b) have a mix of old and new systems (mostly old) which seem like they may struggle more with responding in the higher chatter environment.

The volume explanation was particularly interesting as I see my group volume controls keep automatically reverting over my finger-slide adjustments - I guess in response to the laggy feedback from the devices

Thanks

Sonophone or sonopad app iOS £2.99 will let you control both S1 and S2 devices from one app, and currently may give you a better experience…..

Absolutely possible, @chambolle, with some overhead. Each track needs to be analyzed to produce a “I’m this loud” number, which is typically saved in the metadata (ID3 tag) with the track. That is used to adjust volume during playback. That explanation applies to local library music, naturally.