Hacker News Reader

I wouldn't classify myself as someone particularly "skilled in the art", though I've definitely built audio DSP solutions. I can think of 2-3 ways to achieve "wireless control system and protocol for multiple speakers that can be grouped" while just sitting here.

In classic infringement avoidance ridiculousness, I have no desire to dig into the details... but this superficially feels like it would fail the obviousness test for patentability.

Everything seems obvious in hindsight.

I think the true innovation and problem that Sonos solved when they started was to have synchronised compressed audio streams play on multiple speakers with do audible delay between them. That is not a partially "easy" problem to solve, and bear in mind that when they started they had to implement their own wifi network for the speakers as the wifi standards of the time (from memory) both wouldn't provide the necessary bandwidth but also few people had wifi at the time. The were no smart phones when they stated, they had their own "smart" remotes even.

> Sonos solved

Sonos aren’t popular here at HN due to some truely awful decisions they have made.

I really like my small system and it works great - mostly.

You hit some seriously rough edges if you have a Unifi network, and Sonos’s use of STP rather than RSTP is system breaking until you realise it. And even when you solve this issue, there will be random outbreaks of dysfunction and failure to connect.

The Sonos app is terrible, and the integration with Spotify occasionally craps out - logging out and then in again can fix it, sometimes.

I like the system but it’s got a way to go.

You are quite right, it does have rough edges and certainly more than 10 years ago when we started buying into their system (we have four rooms covered by 8 speakers now).

The Spotify bug when it randomly cuts our is REALY annoying, it seems to happen in a cluster about once a week.

Fortunately we weren't effected by their incredably ill conceived changes to the "legacy" speakers, they deserve criticism for that and I'm sure I would be less charitable if we had been effected.

> Everything seems obvious in hindsight. > That is not a partially "easy" problem to solve

I'm curious if we could re-invent it, right here in this thread, without looking up how it's done.

Have each speaker transmit a little packet with a timestamp 10 times per second to each other. Or relative to some designated central point. Each speaker will have an internal clock but use the central clock tick to keep exactly synchronized.

Having synchronized their timestamps, the central hub transmits a specific time for playback to begin. At this point you need to make sure that there isn't any unexpected buffering going on, output buffers have to be tiny/realtime or the process of sending signal out has to be again synced to the clock, which means you need control over the firmware/drivers. Worst case you might have to skip or repeat a couple samples once in a while to keep synced up which in a 44000 samples per second signal is not a big deal.

You need a big enough input buffer to play a few seconds of audio, just to be safe, but the output buffer has to be realtime.

That's pretty much how I'd do it, off the top of my head.

> to have synchronised compressed audio streams play on multiple speakers with do audible delay between them. That is not a partially "easy" problem to solve,

Without commenting on the radio side of this, I implemented automatic synchronisation of video playback units to within a few microseconds in 2007 and it was fairly obvious how to do it back then. That's accurate enough for audio as well.

So long as units were playing the same content or equivalent-length content (for video walls, shows etc.) and could receive each other's broadcasts on whatever LAN they were connected to, they would automatically detect each other, form equivalence groups, and adjust timing until the clocks matched each other, and stay locked together across content changes.

There was no master control unit, and no configuration; it was an automatic distributed algorithm that "just worked".

> suspect that the outcome of this where Google devices have to have volume controlled individually isn't due to a patent on that specific functionality

I couldn't find the complete list of patent infringements (Sonos alleges more than 100) but it does seem there's one in particular about controlling volume on multiple speakers / rooms at once.

https://www.theverge.com/2022/1/6/22871121/sonos-google-pate...

This seems plausible as the group-volume feature isn't unique to Sonos (and predates them), however their specific means of implementing it likely is unique and patentable.

The patent in question is not about the specific manner in which Sonos implements group-volume. It in fact doesn't even state how Sonos implements it. It is purely about the concept of centrally controlling the volume of local area network connected distributed speakers using a centralized control unit.

Then it should be unpatentable - you should be able to patent a novel technical solution that's necessary for a desirable feature, but not the concept of a feature; patents are for "how to achieve X" not for the outcome.

You aren't supposed to be able to patent an idea or concept but that is what software patents all too often do which is one of the reasons they are so awful. For instance this patent covers having a controller which presents a UI to raise, lower and mute/unmute the volume of a group of network attached speakers. When the user selects to do one of those things the controller communicates over the network to the group of speakers to raise, lower or mute/unmute their volume. The specific technology which implements this ability, i.e. how the controller communicates with the speakers, is not part of the patent. It is purely on having a controller which does the above however it may achieve it.

Edit: Thought I would point out that when Sonos first filed their claims they made a big noise about Google using the same protocol as they to do to control their speakers. This protocol isn't covered by the patents in question. The reason is that the protocols in question are UPnP standard protocols.