Skip to main content
Answered

Interesting read on how sonos is changing


Forum|alt.badge.img+8

 

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.

Best answer by sigh

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.

 

View original
Did you find what you were looking for?
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

92 replies

press250
Forum|alt.badge.img+14
  • Prodigy III
  • 633 replies
  • July 9, 2024

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


Forum|alt.badge.img+8
  • Author
  • Prodigy II
  • 269 replies
  • July 9, 2024

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


Forum|alt.badge.img+16
  • Prodigy II
  • 1889 replies
  • July 9, 2024

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 .


Forum|alt.badge.img+8
  • Author
  • Prodigy II
  • 269 replies
  • July 9, 2024
Rhonny wrote:

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


Forum|alt.badge.img+10
  • Headliner I
  • 268 replies
  • July 9, 2024

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.


press250
Forum|alt.badge.img+14
  • Prodigy III
  • 633 replies
  • July 9, 2024
Rhonny wrote:

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. 

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.

[...]

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.

 


Bumper
  • 1767 replies
  • July 9, 2024

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. 
 

 


Forum|alt.badge.img+1

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.


jgatie
  • 27621 replies
  • July 9, 2024
coletrickle26 wrote:

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!!!”


Forum|alt.badge.img+16
  • Prodigy II
  • 1889 replies
  • July 9, 2024

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???? 


Forum|alt.badge.img+10
  • Headliner I
  • 268 replies
  • July 9, 2024
Rhonny wrote:

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.


press250
Forum|alt.badge.img+14
  • Prodigy III
  • 633 replies
  • July 9, 2024
Rhonny wrote:

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?

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.


Forum|alt.badge.img+16
  • Local Superstar
  • 1731 replies
  • July 9, 2024
press250 wrote:

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.


jgatie
  • 27621 replies
  • July 9, 2024

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.


Bumper
  • 1767 replies
  • July 9, 2024
sjw wrote:
press250 wrote:

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.

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 🤣 


controlav
Forum|alt.badge.img+23
  • Lead Maestro
  • 7522 replies
  • July 10, 2024

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


press250
Forum|alt.badge.img+14
  • Prodigy III
  • 633 replies
  • July 10, 2024
controlav wrote:

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. 


Forum|alt.badge.img+6
  • Enthusiast II
  • 167 replies
  • July 10, 2024

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.


Moyawang
Forum|alt.badge.img
  • Lyricist I
  • 1 reply
  • July 10, 2024

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.

 


Forum|alt.badge.img+6
  • Enthusiast II
  • 167 replies
  • July 10, 2024

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?


Forum|alt.badge.img+16
  • Prodigy II
  • 1889 replies
  • July 10, 2024
chambolle wrote:

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. 


controlav
Forum|alt.badge.img+23
  • Lead Maestro
  • 7522 replies
  • July 10, 2024
Moyawang wrote:

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.

 

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.


  • Lyricist I
  • 2 replies
  • July 10, 2024

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


Forum|alt.badge.img+8
  • Author
  • Prodigy II
  • 269 replies
  • July 10, 2024
Garrym0460 wrote:

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…..


press250
Forum|alt.badge.img+14
  • Prodigy III
  • 633 replies
  • July 10, 2024
chambolle wrote:

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?

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.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings