4 ms·
I was upset at the time, but in hindsight, and given how they've managed to continue to support both S1 and S2 product lines, I can't really say they did it wro
by djrogers 5y ago
I was upset at the time, but in hindsight, and given how they've managed to continue to support both S1 and S2 product lines, I can't really say they did it wrong. Bifurcating your app to continue to provide support for 10+ year old hardware is a lot better than simply EOL'ing said hardware.
- bluescrn 5y agoThe problem is that '10 years old' in computing is fairly ancient, whereas in hi-fi, quality hardware will keep going for many decades with minimal maintenance. Not sure why they felt the need to split the app into two rather than support the control of all devices through a single app, even if the S1 devices have a bit less functionality, or if S1 and S2 devices can't be grouped into a single zone. And then they've prevented some new devices from running with the S1 app. My parents tried to buy an extra speaker, but it didn't work with their S1 system (whereas only a few months ago, they added a soundbar that worked fine) It's a mess. It could have been handled a lot better. What new features do you even get with S2 that require more powerful hardware?
- avianlyric 5y ago> What new features do you even get with S2 that require more powerful hardware? * Airplay * Hi-res audio formats * Better onboarding experience (BLE based, and can take advantage of iOS APIs to share Wifi password) * Support for DTS and Dolby Atmos I suspect the reason for bifurcation is because the speakers form a cluster on your network. The apps don’t talk to individual speakers, the speakers elect a cluster leader and the app talks only with the leader. The leader then figures out how to get your command to the target speaker, which may be via your normal wifi, but could also be via the private Sonos Net mesh network the speakers form. They want all the speakers to run exactly the same firmware because it’ll significantly reduce the complexity of their net code. No need to write forward or backwards compatible protocols, every speaks the same language. Side effect of this choice is that your firmware features become limited by your oldest hardware, even with feature flags, binary size could still be an issue for old devices. So this means at some point you need either: 1. Start running two firmware versions, and some how make your net code forward/backwards compatible. Very difficult when dealing with tightly defined high entropy protocols needs for low latency comms, and super tight timing requirements. 2. Split make a set of your devices stuck on old software and incompatible with new hardware. So new and old can no longer join the same cluster. But simplify your net code. Sonos obviously chose option 2, and I can understand why they made that choice. As for the apps, having them communicate with two different Sonos clusters, and somehow merge the UI sounds like a UI nightmare. Not unsolvable, but it wouldn’t surprise me if they tried it, and decided the experience was so crap and confusing, they were better of just making two apps. Given what Sonos do, and rather extreme technical requirements of syncing audio to within a millisecond or two over dodgy wifi connections. I can sympathise with the difficult technical and product decisions that led to S1/S2. I personally doubt it’s an artificial limitation created for cynical profit pumping. But I can totally see it as way of reducing their software development complexity and costs, which is not an unreasonable business decision (Sonos isn’t a charity after all).