Agreed for anything that has to coordinate multiple packets, like video and audio streaming. 3 way localized handshakes sound great in theory, but in practice result in a lot of lag as nodes wait for their neighbors so to catch up.
I’m one of those that believe this is best handled by end to end provisioning for specific streams, but obviously that’s another argument for a very smart hub like ST to manage traffic and force delivery in the right sequence. Basically creating de facto traffic classes even if it’s just the scheduler (hub) creating them virtually. And I think you need extra physical repeater nodes to make it work, which increases cost.
Another alternative is separate networks run from the same hub, again creating de facto traffic classes. I know some people argue for those, I just think dedicated nodes are messier than a smarter scheduler, especially in a residential setting where the homeowner may physically move things around.
So, yes, I agree Sonos is ahead of the QOS curve, but these problems have been known for years, I expect they’re being addressed one way or another. We’ll see.
(Translation of engineer speak above: mesh networks by their design don’t offered a guaranteed routing path from hub to end node. “Issue once, try many.” That creates the equivalent of buffering issues: packets arrive out of order, or bounce unpredictably creating odd lag or gaps. The whole point of a mesh network is to give the nodes permission to try alternate routes if a neighbor is temporarily unavailable.
Trying to force a way through for things that must arrive in a specified sequence, like a song, requires either making each node able to recognize different priorities (“traffic classes”) or making a central scheduler VERY smart or setting up a separate dedicated network which is expensive.
This is what keeps engineers up at night–you can design a perfect sensor net installation and then somebody wants to broadcast music on it.
So, QOS = quality of service from the end user’s point of view, which means messages arrive in a timely fashion in the order expected without lag or gaps or static. A QOS device usually does one of the things described above: prioritizes or reserves resources to improve end user perception of experience.
Mesh networks were originally designed to improve energy use in installations with relatively dumb, relatively cheap devices, many of which were battery operated. The whole idea was that some devices would be temporarily unavailable occasionally, if only because the batteries were being changed. Not an easy match with a use case like streaming music.)
*Edited to add:
And before someone starts trying to code a way around this, the goal isn’t to deliver packets in sequence. We could run a wire and do that. The goal is to deliver high QOS while retaining the cost, energy, and resiliency benefits of a mesh network. Which is what makes this an engineering problem in the first place.