5 ms·

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 "

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.

samwillis 5y ago
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.
- lostlogin 5y ago
  > 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.
  - samwillis 5y ago
    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.
- nomel 5y ago
  > 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.
  - fallingfrog 5y ago
    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.
- jlokier 5y ago
  > 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".

samwillis 5y ago

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.

lostlogin 5y ago
> 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.
- samwillis 5y ago
  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.
nomel 5y ago
> 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.
- fallingfrog 5y ago
  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.
jlokier 5y ago
> 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".