The Open Home Foundation is a big player in the smart home space, and ESPHome is one of the most influential software development packages in the space. You can define device configurations using a combination of YAML declarations and C++ lambdas, significantly lowering the barrier to entry for most people while still allowing for the deployment of incredibly powerful software. Because of that influence, it’s often worth paying attention to what ESPHome and the wider Open Home Foundation ecosystem are quietly working on. One such project has now stepped into the spotlight: Sendspin, a new open multimedia streaming and synchronization protocol previously known as Resonate.

Sendspin is described as a multi-device and multi-room music and media experience protocol, but that description honestly undersells what it’s actually trying to solve. Rather than being a standalone music player, Sendspin acts as a synchronization and delivery layer that existing audio backends can plug into. The goal is to turn disparate hardware, such as DIY speakers, displays, lights, and embedded devices, into a Sonos-like system, but using open standards and hardware you already own.

All of this is still very much a tech preview, but the foundations are very solid. I’ve been able to speak with the Open Home Foundation over the last month in order to gain some insight into the protocol, how it works, and what the future holds.

How the Sendspin protocol works

It’s split into four components

Sendspin has four key components that make it work:

• Server
• Client
• Group
• Stream

The Sendspin server is responsible for orchestration. It generates audio streams, manages timing, distributes metadata, album artwork, and (eventually) visualizer data, and keeps all connected devices in sync. In practice today, that server role is handled by Music Assistant, which is why Sendspin already feels unusually integrated compared to many early-stage protocols.

Clients are the devices that connect to the server. Crucially, Sendspin doesn’t treat all clients as identical. Instead, each client declares one or more roles during its initial handshake. Today, there are five defined roles:

• Audio player
• Controller
• Text metadata displayer
• Artwork displayer
• Visualizer

A group is where Sendspin’s real magic happens. Groups are collections of clients connected to the same server and playing the same stream in unison. The stream itself is generated server-side and delivered over a WebSocket connection, using Opus for efficient, high-quality audio. Anyone can run a Sendspin server right now, and clients can discover it using mDNS.

A single device can implement anywhere from one to all five roles. For example, a speaker might only implement audio player, while an e-paper display might only implement artwork displayer and text metadata. The server only sends each client the information it explicitly asks for. It can broadcast everything to everyone, but devices can also pick and choose what they subscribe to receive.

Finally, visualizer support is planned. The idea is that the server will handle things like frequency and beat analysis, then send that data to clients implementing the visualizer role. That part of the spec isn’t finalized yet, but it’s explicitly on the roadmap.

Handling synchronization and drift

And how it differs from Snapcast

Multi-room audio lives or dies on synchronization, and this is where Sendspin is doing a lot more than just reimplementing an existing idea. After all, on a high-level, this all may sound similar to Squeezelite and Snapcast, but there’s a reason the Open Home Foundation is investing resources to developing Sendspin rather than incorporating Snapcast. According to Marcel Veldt, founder of Music Assistant, Snapcast "has so many downsides and on top of that the maintainer is not very interested/active anymore." Meanwhile, Sendspin is planned to be capable of switching codecs on the fly, and uses WebSockets to ensure uninterrupted connectivity.

While I would be amiss to not reference the "competing standards" meme, it sounds like Snapcast posed a genuine problem that Sendspin aims to solve. As Veldt explains, it seems like there weren’t many other options aside from creating a new protocol.

It’s a bit of shame to not use the strength of an existing audio streaming protocol (snapcast) but we ran into so much trouble it became more of a burden than a help. I even considered rewriting Snapcast from scratch in python, so keep the binary protocol the same but just re-implement it with our issues fixed.

In order to keep audio sychronized, clients frequently send time-ping messages to the server to determine their clock offset. Rather than trusting a single timestamp, clients filter server responses to account for network latency, jitter, and the natural drift of their own internal clocks. Once playback starts, synchronization is maintained by subtly adding or removing individual interpolated audio samples, usually every few seconds.

If a device’s clock is especially unstable, it will compensate more frequently. If it’s stable, adjustments happen less often. Either way, the goal is that these corrections are completely inaudible.

Network issues are handled pragmatically. Sendspin uses WebSocks over TCP, so packet loss is automatically handled via retransmission. Each client buffers a small amount of audio in advance, which helps smooth out random network hiccups, while delayed or resent time messages are automatically filtered out by the clock synchronization logic.

Versioning, hardware requirements, and key specifications

The Home Assistant Voice Preview Edition can already use it

One of the more impressive aspects of Sendspin is its versioning strategy. Rather than versioning the entire protocol monolithically, Sendspin versions roles. A role like player@v1 has a strictly defined message format and behavior, and that version will never change in a breaking way. If new ideas emerge, a new version such as player@v2 can be introduced while player@v1 remains fully supported. Because each device connects independently, this allows different generations of hardware to coexist in the same synchronized group. A player@v1 speaker can play perfectly in sync with a newer player@v2 device, without either side needing to care.

On the client side, Sendspin has so far been tested most extensively on the Home Assistant Voice Preview Edition, which uses an ESP32-S3 with PSRAM running ESPHome. With some configuration, it should work on any ESP32-S3-class hardware, and likely other ESP32 devices with PSRAM, though broader testing is still ongoing. It’s worth noting that voice control is not part of the Sendspin specification itself, even though the first target hardware happens to be voice-capable. Instead, voice interaction is expected to come from higher-level systems like Home Assistant, which can already control Sendspin-based players, including via voice, without the protocol itself needing to understand speech.

In terms of usability, I already got Sendspin up and running on the Home Assistant Voice Preview Edition, and I was able to get cover art with music controls to show on the WT32-SC01 Plus IPS display. Using those, I had audio on my Mac and the Voice Preview Edition, with track info, controls, and the album art on the display. This was all at the same time as a part of a single player group and was synchronized perfectly. As well, the Open Home Foundation tells me that there’s room for further optimization, meaning that it could make its way to more constrained devices in the future.

On the server side, requirements are minimal. If a device can run Music Assistant, it can almost certainly run Sendspin. It’s already been tested on Home Assistant Green, Intel N100 mini PCs, and Raspberry Pi 4 and 5, and could likely scale down further. I ran Sendspin in a Proxmox LXC (back when it was known as Resonate) with minimal resources granted to it, and it worked perfectly. In terms of scale, the Open Home Foundation tells me that one tester is already synchronizing more than ten players in a single home without issue. The current limit that’s been identified is less about software and more about how many test devices people physically have.

Security, licensing, and governance

Anyone can use it, and the license is open

Credit: Source: Open Home Foundation

Right now, Sendspin uses unencrypted WebSockets for local playback. This is a deliberate choice for early development and trusted local networks. Optional encryption is planned for future versions. With that said, Sendspin is already being used in a secure context: the latest Music Assistant web app can stream audio remotely using Nabu Casa’s WebRTC infrastructure, with Sendspin running inside an encrypted Home Assistant Cloud connection.

From a licensing perspective, Sendspin is released under the Apache License 2.0, making it open, royalty-free, and suitable for both DIY and commercial products. While anyone can implement it, the Open Home Foundation expects to introduce a certification program, similar to "Works with Home Assistant," so commercial products can signal a consistent Sendspin experience.

The protocol’s governance is still evolving, but Open Home projects typically operate via working groups. Development of Sendspin is taking place in the open, and you can even look at the project’s planning and roadmap board to get a sense of how it’s shaping up over time. Specification changes can already be proposed via GitHub issues, pull requests, or discussion channels on Discord, and external contributors are explicitly encouraged to participate. Importantly, Sendspin isn’t trying to replace AirPlay, Google Cast, or other protocols. Instead, it’s designed to coexist with them. Music Assistant can already take an AirPlay stream and redistribute it via Sendspin to other speakers, for example.

If you want to try out Sendspin, it’s now rolled out as a part of Music Assistant 2.7 in your browser. At the time of writing, the Home Assistant Voice Preview Edition has a beta firmware that you can try out, though Paulus Schoutsen, founder of the Open Home Foundation, said that they’re preparing for a stable firmware release to arrive alongside today’s Music Assistant update.

For those using ESPHome, there are external components that have implemented the protocol, and you can use this existing configuration to try it out on the ESP32-S3-Box-3, or modify it to create your own. You’ll need to use ESPHome 2025.12.0, as those external components rely on changes made to the Wi-Fi component in that version. I’ve also published my configuration for the WT32-SC01 Plus over on GitHub to help you get started!