3 ms·

Not sure if you mean that, but the Sonos S1 interface has been reverse-engineered, see here: https://github.com/SoCo/SoCo https://github.com/SoCo/SoCo https:/

by yccs27 4y ago

Not sure if you mean that, but the Sonos S1 interface has been reverse-engineered, see here: https://github.com/SoCo/SoCo https://github.com/SoCo/SoCo https://github.com/jishi/node-sonos-http-api https://github.com/jishi/node-sonos-http-api This allows you to e.g. set the Sonos speakers to play any audio URI.

azinman2 4y ago
And that audio URI is then an ice cast with seconds of latency. This is different for the protocol that the speakers use to pipe audio to each other which is near real time.
- packetlost 4y ago
  It might not be as realtime as you think, especially if it's buffered. You just need to sync timestamps and buffer for at least the slack in your system. I wouldn't be surprised if it was using NTP/PTP under the hood to sync up system clock time and then just playing back a buffer that's shared across all speakers (or just the channel for that speaker with a timestamp). The actual audio transfer probably gets buffered and only the relative timestamp and simple instructions like "play from this timestamp in the buffer" is actually being used to sync up between speakers. It's probably a limitation of the hardware or the lower-level wireless protocol (bluetooth or wifi) that causes that delay. I'm just speculating though, all of my realtime experience is in hard-realtime scientific control systems.
  - squeaky-clean 4y ago
    It's probably a mixture of things. Just tried some of mine with the sonos app and there's always a slight 1-2s delay on play and seeking. But actions like pausing or adjusting the volume are instant. I can pump the volume slider in tempo with the music and there has to be only a few ms of latency.
    - trynewideas 4y ago
      I'd hope so. One of those things (initiating music playback or seeking outside of the playback buffer) involves realtime sequential data transmission, and the other (modifying local settings or playback state remotely without leaving the buffer) is just a byte or two in a packet, if that.
      - azinman2 4y ago
        It’s more than a byte or two — Sonos uses SOAP for RPC.
  - azinman2 4y ago
    If you have a Sonos amp with an input plug, you can play that in near real time. There isn’t much buffering there. It’s low enough latency you can watch video and the lips looks like they match. There’s actually a setting where you can tell it the priority of the audio, which I assume just controls the buffer size.

by yccs27 4y ago

azinman2 4y ago

And that audio URI is then an ice cast with seconds of latency. This is different for the protocol that the speakers use to pipe audio to each other which is near real time.

packetlost 4y ago
It might not be as realtime as you think, especially if it's buffered. You just need to sync timestamps and buffer for at least the slack in your system. I wouldn't be surprised if it was using NTP/PTP under the hood to sync up system clock time and then just playing back a buffer that's shared across all speakers (or just the channel for that speaker with a timestamp). The actual audio transfer probably gets buffered and only the relative timestamp and simple instructions like "play from this timestamp in the buffer" is actually being used to sync up between speakers. It's probably a limitation of the hardware or the lower-level wireless protocol (bluetooth or wifi) that causes that delay. I'm just speculating though, all of my realtime experience is in hard-realtime scientific control systems.
- squeaky-clean 4y ago
  It's probably a mixture of things. Just tried some of mine with the sonos app and there's always a slight 1-2s delay on play and seeking. But actions like pausing or adjusting the volume are instant. I can pump the volume slider in tempo with the music and there has to be only a few ms of latency.
  - trynewideas 4y ago
    I'd hope so. One of those things (initiating music playback or seeking outside of the playback buffer) involves realtime sequential data transmission, and the other (modifying local settings or playback state remotely without leaving the buffer) is just a byte or two in a packet, if that.
    - azinman2 4y ago
      It’s more than a byte or two — Sonos uses SOAP for RPC.
- azinman2 4y ago
  If you have a Sonos amp with an input plug, you can play that in near real time. There isn’t much buffering there. It’s low enough latency you can watch video and the lips looks like they match. There’s actually a setting where you can tell it the priority of the audio, which I assume just controls the buffer size.