New experimental "Sendspin protocol" (formerly "Resonate") for streaming synchronized multi-room audio and hi-fi quality music playback to multiple media player appliances and smart speakers running ESPHome on ESP32 or Linux on Raspberry Pi

[Hedda]

Update: Specification and implementations of Resonate has been renamed to “Sendspin” (i.e. “Sendspin Protocol” “Sendspin Server/Client”):

• https://www.sendspin-audio.com/

  • https://github.com/Sendspin/spec

Update! Music Assistant server now have built-in native support for Sendspin that is enabled by default as an official technical-preview from the Open Home Foundation and development of its server and client implementations are moving very fast:

• https://www.music-assistant.io/player-support/sendspin/

Not sure if this will be usable on all ESPHome based audio output/input devices running on ESP32 (i.e. voice assistants, media player, and smart speaker hardware), but FYI, I heard it sounds like (pun intended) some Open Home Foundation and Music Assistant developers have started working on a new experimental open-source Hi-Fi audio streaming protocol for a better multi-room audio and music playback experience on embedded hardware running ESPHome-based client on ESP32 as well as Linux-based client on the roadmap for Raspberry Pi (Zero):

• https://github.com/Resonate-Protocol (Resonate Protocol organization on GitHub including contact information for collaboration)
  • https://github.com/Resonate-Protocol/spec (WIP specification of the new experimental Resonate multi-room music experience protocol)
  • https://github.com/Resonate-Protocol/aioresonate (Async Python library implementing the Resonate Protocol.)
  • https://github.com/Resonate-Protocol/audio-sdk-js (Proof of concept of how Improv Audio can work in TypeScipt/JavaScript)

This new protocol specification is design from scratch but is similar to Squeezelite and Snapcast as well as Music Player Daemon (MPD) in concept at a high level, Resonate is not a stand-alone player, but an extension that can turn an existing audio player into a Sonos-like multiroom audio solution with time synchronized between the clients and the server to play perfectly synced audio. In their own tests they claim to see that average time deviation is below 0.05ms for synced audio (50 microseconds between two ESP32-S3 devices running ESPHome and connected over WiFi). Think of it like a completly royalty-free and open-source competition to Apple AirPlay (formerly AirTunes) and Google Cast (Chromecast Audio) propriatory protocols but for implementing HiFi multi-room audio solutions.

“Resonate is a multi-room music experience protocol. The goal of the protocol is to orchestrate all devices that make up the music listening experience. This includes outputting audio on multiple speakers simultaneously, screens and lights visualizing the audio or album art, and wall tablets providing media controls.” “Definitions; Server, a Resonate server. Orchestrates all devices. Generates an audio stream, manages all the players, provides metadata etc… Player, a Resonate client that can play audio, visualize audio or album art or provide music controls”.

Resonate Project Board (Backlog and Roadmap):

• https://github.com/orgs/Resonate-Protocol/projects/1/views/1
  • https://github.com/orgs/Resonate-Protocol/projects/1/views/4

Btw, Music Assistant lead developer posted a reply in their discussion section answering the question why they choose to not just use Snapcast:

• https://github.com/orgs/music-assistant/discussions/3883

With this new "Resonate" protocol the Music Assistant client/server and ESPHome will also get a new experimental audio player component that adds support for the this "Resonate Protocol" for synchronized music-playback across multiple devices, (i.e. audio synchronizer between ESPHome-based to enable sound-sync timing for DIY multi-room audio players), as well as ability to also switch codecs on-the-fly.

For a WIP reference implementation of a server using their aioresonate (Async Python library see how it is implemented in Music Assistant:

• https://github.com/music-assistant/server/tree/resonate/music_assistant/providers/resonate

⚠️ Note! The work-in-progress audio client component for the ESPHome firmware is still very much experimental and in early proof-of-concept phase, not near ready for production use, and the availabe code made available is just intended for testing or feedback purposes only. ⚠️

Update:

• [generic_image][sendspin] (WIP) Add Sendspin synchronized audio protocol esphome/esphome#14933

Above replaces:

• [sendspin] (WIP) Add Sendspin synced audio protocol support esphome/esphome#12284

and

• WIP: Resonate synchronized audio component esphome/esphome#10183

Implementation Details:

• Time Synchronization:

  • Employs a Kalman filter to model and compensate for internal clock drift between the client and server
  • Dynamically tracks and adjusts for each device's clock characteristics to maintain tight synchronization
  • In preliminary testing, achieved a median audio synchronization error of approximately 50 microseconds between two ESP32-S3 devices connected over WiFi.

• Architecture:

  • The resonate component implements a flexible hub architecture that allows devices to participate in the audio listening experience with different levels of functionality:
    • Text Sensor: Display track metadata without audio playback (e.g., on screens)
    • Media Player: Output synchronized audio
    • Extensible Design: Ready for future integrations like audio visualization

• mDNS:

  • Implements mDNS advertisement for the component's WebSocket server
  • Enables automatic discovery by resonate servers

• External Dependencies:

  • Integrates esp-libopus (WIP IDF component) for Opus audio codec support

• Testing:

  • Currently compatible with:

    • Music Assistant Server - feat/improv-audio branch
      • Note: This implementation has known issues but provides basic testing capabilities for synchronized playback

  • Example entry for config.yaml:

    • Example Voice Preview Edition firmware is available here: https://github.com/esphome/home-assistant-voice-pe/blob/resonate-dev-snapshot1/home-assistant-voice.yaml (requires building with ESPHome dev branch)

• Current Status:

  • August 28-29th updates adds several important changes:
    • Now compatible with the Music Assistant server's resonate branch
      • https://github.com/music-assistant/server/tree/resonate/music_assistant/providers/resonate
    • Fixes issues with rapid stopping and starting (requires using the mixer and resampler speaker platform changes in this PR)
    • Improves memory handling and safety
    • Adds groundwork to support cover art as an image component in ESPHome
      • This PR is intended for testing and feedback purposes only. The implementation contains:
        • Numerous TODO items for simplification and optimization
        • Extensive debug logging for diagnosing synchronization issues
        • Incomplete features pending server-side support (metadata processing, FLAC decoding)
        • Breaking changes expected in future iterations
        • Modified Components

• Future Work:

  • Protocol refinement and stabilization
  • Enhanced audio stack to support additional synchronized audio protocols
  • Complete metadata and FLAC support
  • Production-ready implementation

There was some discussions + further explainations on its concept in a other thead that asked about this new multi-room streaming protocol:

• https://github.com/orgs/music-assistant/discussions/3883

Originally posted by @marcelveldt in #3883 (comment)

"we decided to create (yes, yet another!) protocol. One that would fulfill all our needs and would work across the internet and suitable for low powered devices like the ESP32. It will support (perfect) synced playback by default but can also switch codecs on the fly, making it suitable to stream to a (remote) browser. Based on websockets ensures it can travel across firewalls, reverse proxies and whatnot. 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. I'll make sure we publish the details somewhere soon, currently its still in ideation/POC phase but looking very good. "Be aware that this is nowhere near ready to test something - we are still defining the spec and doing some PoC implementations to test the theory."

If I understand correctly this new Resonate synchronized audio component will add a flexible hub architecture for audio time synchronization

• https://github.com/Resonate-Protocol/spec

This could solve the problem that you normally need more expensive hardware solution if you want to add multi-room audio to existing speakers, as once this is implemented fully you could have almost perfect multi-room audio syncronization using something like the Home Assistant Voice Preview Edition connecte to external speakers using its stereo output jack:

• https://www.home-assistant.io/voice-pe/

But a more relevant follow-up feature request for Music Assistant when this implemented would be if could add support for different types of multi-room audio, (to have options for single source-single zone, single source-multiple zone, or multiple source-multiple zone playback)?

• https://en.wikipedia.org/wiki/Multi-room_audio

Ongoing discussion about this new experimental Resonate audio component is going on in this Discord channel here:

• https://discord.com/channels/753947050995089438/1369735163629801532

KevinA:
"Luckily math is here to save the day 😆 . A Kalman filter is a nice way to combine measurements with different uncertainties, which is exactly what we have! Basically, if the most recent message has a very low delay, then we weigh its value much more than if it had a very high delay. It gives us a much more stable offset than using the median, but it also gives us an estimated error after each update. This means the client can estimate how accurate its own offset is! This would allow us to slow down or increase the pace we send the time messages. The more confident we are in the offset, the less we need to send - and vice versa. This will be especially helpful when we first connect and need to spam a bunch of time messages to quickly build our confidence in the computed offset.

So being accurate is important, of course, but being stable is also very important. The median was problematic, even if its inaccuracy wasn't audible. With the median filter, the offset would shift by over 200 microseconds, on average, per update, which means the client would have to constantly be tweaking the audio to try to stay in sync. With very big jumps, it would require hard syncing which is audible.

The Kalman filter modeling the drift (of 2 seconds per day) had an average offset change of only ~25 microseconds per update. Keep in mind, if the clock does drift 2 seconds per day, we would expect it change 23 microseconds per update if the updates are 1 second apart. If there is no systematic drift in the client clock, the Kalman filter had an average change of less than 1 microsecond per update."

Btw, looking at the commit history it seems like "Resonate" used to previously be refered to as "improv-audio" internally by its developers:

• music-assistant/server@dev...feat/improv-audio

PS: Somewhat ironically the Open Home Foundation recenrly posted a newsletter blog post titiled "" and then they choose to use xkcd's "standards" classic XKCD comic strip on how standards proliferate as their tumbnail for the Resonate organization on GitHub, however with the Open Home Foundation, Home Assistant , Music Assistant, and Nabu Casa founder backing this they probably have the influence to at least convince many open-source based media layer implementations to also add support for this new protocol:

• https://newsletter.openhomefoundation.org/why-isnt-there-one-standard/

[trisweb]

A few questions come to mind:

What is the audio quality of this new protocol?

Does it support high resolution audio?

Does it use lossless encoding?

Does it support clients other than ESP32 based microcontrollers?

[OzGav]

The protocol doesn't limit the quality.
Yes
Can do
Yes

[Hedda]

@trisweb It is also important to remember that even if the protocol specification supports higher quality or more features then each client implementations can still have suffer from poor implementation of required standards. Meaning it will probably primarly be hardware devices/appliances that will limit the top performance. Like example the Home Assistant Voice Preview Edition hardware board which just uses a TI AIC3204 (TLV320AIC3204 audio codec and DAC) for its 3.5 mm stereo headphone audio output jack which is relativly low-end and limits it to 48 kHz sampling rate output. So to get higher sampling rates outputs then you either need to use different hardware with a better DAC if you want analogue output directly or find a solution that provide digital output compatible with other encodings so that you can use an external audio decoder (audio codec) and DAC (Digital to Analog converter). The great thing is that not only is this new protocol specification is completly royalty-free and open-source but the Open Home Foundation has also created an open standard for the hardware too (so the Home Assistant Voice PE hardware is more or less just a proof-of-concept and development platform to build upon), which means anyone can make compatible hardware that is much better:

• https://www.home-assistant.io/blog/2024/12/19/voice-preview-edition-the-era-of-open-voice/

Anyway, while I do not know more than what is written in the current specification of the Resontate protocol (which is a living work-in-progress with nothing set in stone), I would still assume we can make an educated guess that their long-term plan is for the specifications in this new protocol/standard to either be better or at least have feature-parity with all the "competing" player provider protocols, meaning it should in the future best or match the features and functions of all the other player providers listed in the player capabilities comparison table here (where it right now on paper looks like Squeezelite is the one they need to best today in the case of pure audio quality, though upstream Snapcast and MPD also support higher audio quality and more features):

• https://www.music-assistant.io/player-support/

[Hedda]

@marcelveldt do you plan to make a default/reference "Resonate Media Player" Linux-based client to run on Raspberry Pi hardware?

Perhaps even a complete "Hi-Fi" media player client Linux distribution (based HAOS/HassOS if not LibreELEC OS or similar JeOS Linux distro)?

That is, as there is no guarantee that third-party media players will adopt/implement support for this Resonate protocol I was wondering it the Open Home Foundation plan to make a reference media player software application for Linux that support Resonate protocol on Raspberry Pi?

Asking since Raspberry Pi running Linux is today probably the most popular platform for DIY line-out WiFi client solution for multi-room audio.

Suggesting a stand-alone all-in-one music player component package for Linux to make it simple to setup a Resonate client media player and achieve audio synchronized playback that more or less matches what kahrendt is developing for ESPHome here, (but for Raspberry Pi instead):

• WIP: Resonate synchronized audio component esphome/esphome#10183

Example a Raspberry Pi with either HiFi DAC + Amplifier hardware HATs or a USB Audio Device Interface adapter for audio output like these:

• Sonocotta Raspberry PI Media Center (open source hardware Hi-Fi DAC + Amp HATs for Raspberry Pi from @sonocotta / @anabolyc)
  • https://github.com/sonocotta/raspberry-media-center
• HifiBerry (probably at this time the most popular DAC/AMP HAT products for the Raspberry Pi)
• Pimoroni Pirate Audio (series of HATs for Raspberry Pi)
• Raspiaudio Pi Audio Drive (Raspberry Pi 5 expansion board with HD DAC, audio I/O and AMP)
• IQaudio DAC HAT (no longer being manufactured?)
• JustBoom DAC HAT (no longer being manufactured?)
• Volumio (commercial music network streamer OS based on MPD that run on Raspberry Pi which can also be used on DIY hardware)
• RuneAudio (abandoned open-source music streamer with "RuneOS" disto based on MPD player that was designed to run on Raspberry Pi)
• Behringer USB Audio Device Interface adapters (ex. their UCA222 and UCA202 which has analog line-out + optical S/PDIF out + line-in)
  • For reference, this type of SB Audio Device Interface adapter will probably be the easiest for developers and testers to get started with.

PS: FYI, indirectly related is that synesthesiam begun working on a Linux-based Voice Satellite for Home Assistant using the ESPHome protocol (i.e. porting ESPHome to Linux) as the successor/replacement for Rhasspy's Wyoming Satellite remote voice satellites on Raspberry Pi hardware:

• https://www.reddit.com/r/homeassistant/comments/1na1chk/new_wyoming_satellite_successor/

  • https://github.com/OHF-Voice/linux-voice-assistant

Quoting synesthesiam comment/reply on that Reddit:

Author here, glad to see so much interest :)

To give some context: the Wyoming protocol was developed for voice services like speech-to-text, text-to-speech, etc. I added satellite messages early on so we could use Raspberry Pi's alongside the ESPHome devices. Over time, the Wyoming Satellite feature set has fallen behind ESPHome and it's felt like I'm basically recreating the ESPHome messages in Wyoming.

So I had the idea: why not just implement a tiny subset of the ESPHome protocol on Linux and reuse what's already there? This turned out to be way easier than I expected! It also has the benefit that I can expose the media player properly now, and it will be possible to expose LED rings and buttons too in the future without any changes to Home Assistant. The Raspberry Pi satellite just looks like an ESPHome device with the proper entities already in place.

At the moment, this project only supports microWakeWord but I'd like to add openWakeWord support soon (PRs welcome). I'm also using the mpv media player directly now for audio output so I can mix audio streams properly. Things like timers, announcements, start conversation, audio ducking, etc. all just work out of the box. It should also be possible to use PipeWire/PulseAudio plugins for acoustic echo cancellation (AEC) so the wake word can still be heard over music.

The next step will be to add a proper tutorial and start collecting feedback from beta users :)

[marcelveldt]

Yeah, @maximmaxim345 is going to implement a full functional client into the aioresonate library

[Hedda]

@maximmaxim345 any plan to implement the aioresonate library into the Linux voice assistant project that synesthesiam is working on?

• https://github.com/OHF-Voice/linux-voice-assistant

[trisweb]

General +100 to a Linux client. Ideally a fully functioning service one can run in place of squeezelite.

[maximmaxim345]

@maximmaxim345 any plan to implement the aioresonate library into the Linux voice assistant project that synesthesiam is working on?

No plans yet, but shouldn't be too difficult to add once the linux client is ready.

[Hedda]

@maximmaxim345 have you by the way looked at Matter Casting APIs & architecture to see if it has any good concepts that can be borrowed?

• https://github.com/project-chip/connectedhomeip/tree/master/examples/tv-casting-app

  • • https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-casting-app/APIs.md

• https://github.com/project-chip/connectedhomeip/tree/master/examples/tv-app

  • https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-app/linux/README.md

PS: One major limitation is the the current Matter Casting specification is that they are still missing support for the audio-only part of its architecture as their casting technology focus so far has just been on video streaming and this there is not yet any audio-only APIs or examples for smart-speakers or music-recievers, but I understand that some Connectivity Standards Alliance members have started to look at that now:

• [Feature] Matter Casting support for "Audio Player Architecture" with a new "Casting Audio Player device type" and "Audio Player endpoint" ("Casting Audio Player" and adding "Basic Audio Player") + look into adding multi-room music streaming for "Matter Speakers"? project-chip/connectedhomeip#31389

[Hedda]

Maybe should have posted the idea here instead, but wondering if can get a Resonate Protocol and ESPHome solution for these use cases? See:

• Add a "Source Role" for audio input devices so hardware can have Line-Level Audio input and can act as a Sendspin audio source? Sendspin/spec#14

What it would basically achieve is enable network-attached stereo sound input device for analogue HiFi sources that digitize and stream audio:

• Music provider solution(s) in Music Assistent to digitize and stream audio from analog AUX input sources to other player providers in MA? Any easy way to achieve a remote AUX input into Music Assistant to enable remote network streaming from an external analog audio source like a vinyl record player (LP turntable) or cassette player?

See ESP32-based draft prototype for a ESPHome proof-of-concept development kit hardware (PCB schematic design by @alextrical) here:

• https://github.com/alextrical/ESPHome-LineLevelADC

Related discussion and request for help with ESPHome Audio ADC drivers and pipeline for streaming audio from ESP32 to Music Assistant:

• ESPHome as Audio input with PCM1808 ADC

PS: The concept described really need to do beyond the request with the of Music Assistant Server using a sound card input as local audio-in:

• Request: Local Audio-In as a provider

[Hedda]

FYI, Music Assistant 2.7.0 BETA 0 release has now added an initial (experimental) MA music provider for this new Resonate streaming protocol:

• https://community.home-assistant.io/t/music-assistant-2-0-your-music-your-players/727626/1776

  • Add Resonate Provider server#2348

    • https://github.com/music-assistant/server/releases

Note that there is still not yet any Resonate clients released so those you currently need to build yourself if you want to experiment with this:

• WIP: Resonate synchronized audio component esphome/esphome#10183

• https://github.com/Resonate-Protocol/aioresonate

• https://github.com/Resonate-Protocol/audio-sdk-js

[Hedda]

@maximmaxim345 what is the current overall status of the Resonate specification/protocol and reference server/provider and clients/players?

@kahrendt Any chance we will see an experimental player be merged into ESPHome and/or linux-voice-assistant before the end of this year?

[maximmaxim345]

@maximmaxim345 what is the current overall status of the Resonate specification/protocol and reference server/provider and clients/players?

The protocol specification is not yet fully finalized, but we are getting very close to that.
As for implementations, we will soon have:

• A almost fully spec compliant python server library (now called aioresonate)
• A Music Assistant Provider using aioresonate
• A almost fully spec complaint VPE Alpha Firmware
• A spec compliant python client (now called aioresonate-cli)
• A minimal but spec compliant js library for players
• Experimental Resonate Support in the Music Assistant Frontend using that js library
• A proof of concept Google Cast implementation of Resonate, including synchronized audio
• A highly experimental option to use Resonate for Chromecast devices in Music Assistant

[Hedda]

For reference; the implementation of Resonate has now been renamed to "Sendspin" (i.e. "Sendspin Audio"):

• https://www.sendspin-audio.com

It is however not clear if that will be the final name, so the name and specs are still subject to change.

• https://github.com/Sendspin/spec

You can already stream audio/music via Sendspin using the beta version of Music Assistant (server):

• https://beta.music-assistant.io/

Development on the Sendspin component for ESPHome has been refactored in this new PR here:

• [sendspin] (WIP) Add Sendspin synced audio protocol support esphome/esphome#12284

If can now test alpha/pre-release builds of ESPHome with it for the Home Assistant Preview Edition:

• https://github.com/esphome/home-assistant-voice-pe-alpha/blob/alpha/home-assistant-voice.yaml

  • https://esphome.github.io/home-assistant-voice-pe-alpha/

Or you can today run a Resonate command-line server and client powered by resonate-go yourself:

• https://github.com/harperreed/resonate-go
  • https://github.com/harperreed/resonate-go/releases

If you have any feedback joint the #sendspin-beta-testing channel on the Music Assistant Discord:

• https://discord.gg/DqNuKwKR

PS: It sounds as if Sendspin component will not be merged into ESPHome mainline until next year.

[Hedda]

Originally posted by @marcelveldt in #4200 (reply in thread)

@marcelveldt do you plan to make a default/reference "Resonate Media Player" Linux-based client to run on Raspberry Pi hardware?

Yeah, @maximmaxim345 is going to implement a full functional client into the aioresonate library

@maximmaxim345 any chance or @kahrendt could develop an official Sendspin audio player/client for OHF-Voice's new linux-voice-assistant?

• https://github.com/OHF-Voice/linux-voice-assistant

"Linux Voice Assistant" from the Open Home Foundation is a new experimental Linux voice assistant for Home Assistant that uses the ESPHome protocol, and it is being developed by @synesthesiam as a replacement to his previous Wyoming-satellite (Linux-based remote voice satellites):

• Replace Wyoming satellite with Linux Voice Assistant OHF-Voice/backlog-issues#45

That is, it would be great if that project from the Open Home Foundation also officially fully supported the Sendspin protocol. See request:

• [REQUEST] Sendspin client and audio player (OHF and Music Assistant's prefered protocol optimized for music playback) OHF-Voice/linux-voice-assistant#6

and this additional related request as would be awesome if a such Linux Voice Assistant could also be used as a Sendspin server with local-input:

• [REQUEST] Sendspin client source support for "Local Audio-in" to stream AUX-input from one LVA client to other Sendspin clients OHF-Voice/linux-voice-assistant#46

  That second request is indirecly related to this question/idea about having servers that offers physical Line-Level Audio input as source:

  • Add a "Source Role" for audio input devices so hardware can have Line-Level Audio input and can act as a Sendspin audio source? Sendspin/spec#14

For reference on what the "Linux Voice Assistant" from the Open Home Foundation is about read this quote from synesthesiam's post on reddit:

• https://www.reddit.com/r/homeassistant/comments/1na1chk/new_wyoming_satellite_successor/

To give some context: the Wyoming protocol was developed for voice services like speech-to-text, text-to-speech, etc. I added satellite messages early on so we could use Raspberry Pi's alongside the ESPHome devices. Over time, the Wyoming Satellite feature set has fallen behind ESPHome and it's felt like I'm basically recreating the ESPHome messages in Wyoming.

So I had the idea: why not just implement a tiny subset of the ESPHome protocol on Linux and reuse what's already there? This turned out to be way easier than I expected! It also has the benefit that I can expose the media player properly now, and it will be possible to expose LED rings and buttons too in the future without any changes to Home Assistant. The Raspberry Pi satellite just looks like an ESPHome device with the proper entities already in place.

At the moment, this project only supports microWakeWord but I'd like to add openWakeWord support soon (PRs welcome). I'm also using the mpv media player directly now for audio output so I can mix audio streams properly. Things like timers, announcements, start conversation, audio ducking, etc. all just work out of the box. It should also be possible to use PipeWire/PulseAudio plugins for acoustic echo cancellation (AEC) so the wake word can still be heard over music.

The next step will be to add a proper tutorial and start collecting feedback from beta users :)

[Anachron]

Hey there,

I've spun up the v 2.7 MA container and even though I have sendspin enabled when I click on play it wont show me any players. I thought it would automatically play on the web UI?

Is this because of a misconfiguration? Or what else do I need to do?

I've double-checked that the port is open (telnet from local device to server) and don't really know what else to do.

Even disabled and reenabled the sendspin plugin, but sadly no change.

[Hedda]

esphome 2025.12.0 now supports sendspin. You no longer require special build.

That is not true. It has not been added to mainline ESPHome. The pull request will add the Sendspin component to the upstream ESPHome repository is still open as a draft, so it is not yet merged, see:

• [sendspin] (WIP) Add Sendspin synced audio protocol support esphome/esphome#12284

So not sure why you would think it is invluded in ESPHome 2025.12.0 but neither Sendspin or Resonate PR has been merged into mainline ESPHome and it is not mentioned in the ESPHome 2025.12 changlog, read:

• https://esphome.io/changelog/2025.12.0/

It has only been merged to the ESPHome fork for Home Assistant Voice Preview Edition, which is experimental, so technically you still need a special build even for the Home Assistant Voice PE.

[marcelveldt]

The beta build of VPE has sendspin

[patienttruth]

I have a VPE that I'd like to take between two different network locations (attached to a boom box), so currently I have it set to two SSID after I took control. If I switch to the beta, is there a way to manually or automatically still include updates to the beta software?

[OzGav]

You should ask this question in the HA forums. We don’t control the VPE firmware. Edit: also sendspin is now in the stable build

[Hedda]

sendspin is now in the stable build

To clearify; Sendspin is now included with the official builds for Home Assistant Voice Preview Edition firmware image releases (but not enabled by default in it?)

• https://github.com/esphome/home-assistant-voice-pe/releases

However also note that the Sendspin component has not yet been merged into upstream ESPHome so it is still not offically part of mainstream ESPHome:

• [sendspin] (WIP) Add Sendspin synced audio protocol support esphome/esphome#12284

[Hedda]

FYI, an alternative could be to build new ARM64-based hardware solutions that runs the Linux-Voice-Assistant project is a new experimental voice satellite solution from the Open Home Foundation which will likley get Sendspin audio player client support sooner or later:

• https://github.com/OHF-Voice/linux-voice-assistant

That is, while Linux-Voice-Assistant main purpose is to allow you to build a Linux-based voice assistant smart speaker that runs on any x64 or ARM64 hardware capable of handling local and on-device audio processing, however similar to ESPHome it can also be used without microphone/voice as a just a output-only music reciever/speaker, (i.e. a dedicated network audio streamer).

• Initial Sendspin support OHF-Voice/linux-voice-assistant#113

This approach provides greater flexibility for customization compared to ESP32-based microcontroller hardware. Because it runs on a full Linux system, it also gives you access to significantly more local computing resources for additional features and other integrations on the same satellite.

• [REQUEST] Sendspin client and audio player (OHF and Music Assistant's prefered protocol optimized for music playback) OHF-Voice/linux-voice-assistant#6

Hardware-wise it is primarly designed to run on Raspberry Pi (Raspberry Pi Zero 2 W or Raspberry Pi 3 and better) and used in combination with a audio-HAT for Raspberry Pi GPIO pins, such as example those from HiFiBerry or Sonocotta.

https://github.com/OHF-Voice/linux-voice-assistant

[Hedda]

For reference, missed that this blog post about Music Assistant 2.7 contain an official public introduction to Sendspin meant for MA end-users:

• https://www.music-assistant.io/blog/2025/12/17/music-assistant-2-7/#spin-me-right-round

Introducing Sendspin

For some time, the Music Assistant team has been looking for the best way to stream audio, album art, and other music visualizations to the devices we have around our homes. There are a couple of projects out there doing cool stuff with streaming audio, but not any that fit our needs. So, when it doesn’t exist, it’s time to start building.

Introducing Sendspin, a new multimedia streaming and synchronizing protocol. It’s fully open source and free to use. Sendspin can stream high-fidelity audio, album art, and visualizer data, automatically adapting to each device’s capabilities. Imagine an e-paper display showcasing the album cover, while multiple speakers play in sync, and smart lights pulse to the rhythm.

The best way to use it right now is either via your browser or a Home Assistant Voice Preview Edition running beta firmware. We’ve built the experimental ability to use Sendspin on Google Cast-capable speakers (we’re also looking to do the same with AirPlay-capable speakers), which will allow Sendspin to work with a lot of different hardware.

A big thanks to Maxim and Kevin at the Open Home Foundation, who have been instrumental in making Sendspin a reality. Even though it can do some impressive stuff today, it’s very much a tech preview, and this announcement is our call to all developers and DIY audio hobbyists – we need your help building and testing this. This is the spec, start building with it!

All the best things in life are meant to be shared, and your music should be as free and open as the software we love. So spin that record 💿, drop the needle, and send that music across your entire home.

And then missed that Music Assistant 2.8 introduced the concept of Sendspin Bridges:

• https://www.music-assistant.io/blog/2026/03/25/music-assistant-2-8/#take-it-to-the-bridge

Sendspin Bridges

Before this release, if you wanted to group a Sonos speaker with a Google Nest (via Chromecast), you were out of luck. In 2.8, we’ve introduced Sendspin Bridges, which “wraps” Sendspin around your existing Chromecast and AirPlay-capable devices (such as Sonos). By turning these devices into Sendspin players, Music Assistant can now treat them as one big, happy family. You can finally create a Sendspin Group that mixes and matches brands, keeping them in perfect sync. Your Sonos in the lounge and your Chromecast in the kitchen are finally on the same team!

---

FYI, the founder of Music Assistent and lead of the Open Foundation protocols ecosystem also mentioned in the Music Assistent 2.8 Release Party video that the upcoming State of the Open Home 2026 will have a segment where they will share more on the progress of Sendspin:

• https://www.home-assistant.io/blog/2026/01/20/state-of-the-open-home-2026/

Hopefully they will also share what’s ahead, with a roadmap and/or future plans for Sendspin with wider goals they want to try achieving during this year.

[Hedda]

Tip and FYI, for reference, @RealDeco has published a repository named SendspinZero on GitHub with part-lists and step-by-step instructions needed to build several different variants of compact and minimalistic hardware ESP32-based Sendspin client media players running ESPHome (made for use with Music Assistant server). All are based on around the Waveshare ESP32-S3-Zero dev board, and ESPHome YAML configuration for all variants + 3D-files for 3D.printable cases for each variant + links to where all parts can be sourced from Aliexpress):

• https://github.com/RealDeco/SendspinZero

Note that are variants with and without a display in that repo that add a button and RGB-light or even show album cover art, Song, and Artist on the scrren while playing music (or a weather clock when not playing). Plus a variant with amplifier for analog speaker.

Currently he essentially has three build versions, then there are additional variants of those so you can almost mix and match as you want:

If you want to test the SPDIF output PR he also includes an absolut minimal variant with only a Toslink optical digital audio output module:

And there is a S/PDIF Coax (Coaxial digital audio output) variant which is simpler since it just need two wires and a resistor, which would also be interesting to test because while TOSLINK maximum sample rate limit is 96kHz, the maximum sample rate for S/PDIF Coax is 192kHz, (and both support up to 24bit bit-depth when outputting stereo PCM):

[Hedda]

FYI, another alternative step-by-step guide for a simple DIY seup with ESP32 and SPDIF digital output via ESPHome been posted by @Rudd-O here:

• https://rudd-o.com/linux-and-free-software/how-to-get-100-pure-digital-music-on-your-home-theater-courtesy-of-esphome-and-music-assistant

[Rudd-O]

Thank you for bringing my project to users' attention. We at home are very happy with our media center / HT using exactly this, thanks to the Sendspin folks and @kbx81 @johnboiles working hard to get SPDIF going.

[Hedda]

FYI, the founder of Music Assistant and one of the developers working on Sendspin discussed its origen + future plans during the State of the Open Home 2026 live video stream at 1:01 time-mark:

• https://www.youtube.com/live/XyAL1to3Lm4?si=jyxKu5XxBtvdiPNq&t=3666

For reference, State of the Open Home 2026 covers what Open Home Foundation has done the past year and what it plan to do in the future:

• https://www.home-assistant.io/blog/2026/01/20/state-of-the-open-home-2026/

  • https://sotoh.openhomefoundation.org/

[Hedda]

FYI, Sonocotta developer @anabolyc are now providing a full range of tested and working ESPHome firmware images with Sendspin enabled for use on his ESP32 Audio devices:

• https://sonocotta.com
  • Sonocotta ESP32 Audio boards: https://github.com/sonocotta/esp32-audio-dock/tree/main/firmware/esphome
  • Sonocotta Esparagus Echo: https://github.com/sonocotta/esparagus-echo/tree/main/firmware/esphome/
  • Sonocotta Esapragus boards: https://github.com/sonocotta/esparagus-media-center/tree/main/firmware/esphome

Also, HouseWaves has posted a very detailed step-by-step guide on installing ESPHome firmware with the SendSpin streaming protocol client on the Sonocotta ESP32-LOUD board here:

• https://github.com/HouseWaves/home-assistant-audio-speaker-v2/blob/main/README%20-%20ESPHome%20with%20SendSpin%20Firmware.md

  • https://www.reddit.com/r/homeassistant/comments/1skggdr/v2_60_diy_wifi_bt_audio_speaker_for_home/

    • https://www.reddit.com/r/musicassistant/comments/1sx9egy/update_sendspin_firmware_detailed_instructions/

Note that he himself got issues with stuttering when audio started but someone else had the same symtom workarround by reducing config for the network power using the output_power argument

• https://www.reddit.com/r/musicassistant/comments/1t06mnc/sendspin_time_message_timeouts_and_bad_stuttering/

But then ESPHome 2026.5 should be released in a few weeks and it also contains some fixes like:

• [sendspin] Use sendspin-cpp to v0.4.0 to reduce stuttering esphome/esphome#16178

[RealDeco]

there's a stutterfree (almost) example for wrover devices like sonocotta and raspi muse (proto/luxe) here:
https://gist.github.com/RealDeco/a20db4a46a62c3a81515b20a908a4828

[cociweb]

I know, ESPHome 2026.5 is still in progress, but it works now very well with the latest dev build. Except for the MA playback with opus codec.... ESP says it is a media source error. From HA it is ok, so maybe Music Assistant has some customization when the opus stream is constructed. (Assumed by the doc ) - According to the ESPHome doc : OPUS is only supported with 48kHz)

19:39:49	[D]	[esp-idf:000]�[1;31m[md_reader]�[0;36m	
D (58654643) micro_decoder.http_client: Connected: status=200 content-type='audio/opus'
19:39:49	[D]	[esp-idf:000]�[1;31m[md_reader]�[0;36m	
I (58654644) micro_decoder.audio_reader: Streaming http://<redacted_local_ip>:8097/flow/peYsvHrH/media_player.esp32_a1s_sendspin_media_player/8e57cec294a74008a889a47f9e74d1ba/media_player.esp32_a1s_sendspin_media_player.opus (OPUS)
19:39:49	[D]	[esp-idf:000]�[1;31m[md_reader]�[0;36m	
D (58654652) HTTP_CLIENT: esp_transport_read returned:-1 and errno:128 
19:39:49	[D]	[esp-idf:000]�[1;31m[md_decoder]�[0;36m	
E (58654664) micro_decoder.decoder_source: Decode drained after reader error
19:39:49	[W]	[component:522]	
logger took a long time for an operation (52 ms), max is 30 ms
19:39:49	[D]	[speaker_source_media_player:285]	
State changed to PLAYING
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
19:39:49	[E]	[speaker_source_media_player:222]	
Media source error
.....
19:39:49	[D]	[speaker_source_media_player:285]	
State changed to IDLE

@OzGav Can somebody confirm from the MASS developer side? I'm still unsure is it an ESPHome issue, or MASS issue.

moreover, If I choose a right codec (eg mp3) the playback pause if I choose the prev/next track from the playlist. Even if I click on the seek bar: for the second click on the seek bar, it jumps to the right place then continue the playback from the expected place....

[anabolyc]

I've updated all sendspin configs, both for ESP32-Audio and Esparagus boards, so feel free to give it a try. If you build in the HA, you'll need to install the ESPHome (dev) addon, but in a couple of weeks, it will be available in the standard ESPHome

In my short tests, there were no crashes (good start!), no drops during playback, and almost no stutter from the start. People report some codec incompatibility, so more improvements will follow, but it is very much usable now.

Another apparent change - it no longer uses PR versions for the components, all necessities right now pulled directly from ESPHome - good sign that Sendspin maturity is growing. Also, probably more people will join the beta-testing now

[RealDeco]

he is not using dev. and i don't know why you updated your consumer devices for dev instead of waiting for a release, it is after all mostly non-dev users buying these products 🤷🏼‍♂️, personally my open source projects are also for the average newbie with DIY so i didn't go that way, instead i use older pr's that still works with current release version, while we wait.. if it was for myself only i would just stay on dev but it's not ;)

[RealDeco]

Mine is still 2026.4.5 (no update, that I can see yet).

which sendspinzero device is it you can't get working with 2026.4.5?, analog should still work but spdif is broken until next release.

[galvheim]

Mine is still 2026.4.5 (no update, that I can see yet).

which sendspinzero device is it you can't get working with 2026.4.5?, analog should still work but spdif is broken until next release.

It is not that I cant get them working, but since I started with SendSpin in february, we have gone through many iterations of code setup, tweaking of settings, an many sources of PRs. The main struggle has been to find a vanilla-YAML with latest stable code. Today removed "const" because the old external Sendspin fork was replacing ESPHome’s built-in "const" with an outdated version. That broke the built-in display component, so removing const allowed ESPHome to use its own updated core files again.
ALso it is annoying to find YAML broken out in so many includes linking to github when looking for a "latest" stable code from around the webs. Since I have so many projects going, and not have time to figure out everything, BUT love sendspin and Music Assistant, I am often on a hunt for good stable code.
But why isnt there just a one stable S3 QUAD, S3-OCTAL, WROVER YAML out there?

[RealDeco]

just let your devices be with the yaml that works for you, it's not so long now..
this is the last project i played with that also includes sendspin and it works quite well, though it of course doesn't include the latest fixes and magic the devs made since, but it work. (notice it's after we dropped http_request) so also som other changes to yaml than just the external components) https://github.com/RealDeco/Zero-VA/blob/main/Zero-VA-Sendspin.yaml

[haldi4803]

while we wait..

Because he has some very impatient customers that like to live on he bleeding edge of life.

Just waiting is too boring right?
Most people that DONT care never update their working config anyway.

[Hedda]

FYI, the SPDIF output support has now also been merged so should make it together Sendspin into the upcoming ESPHome 2026.5 release:

• [speaker] Add SPDIF output support esphome/esphome#8065

  "SPDIF Mode - S/PDIF (Sony/Philips Digital Interface Format) mode enables digital audio transmission over optical (TOSLINK) or coaxial digital audio connections. This mode encodes PCM audio data into a SPDIF bitstream format that can be received by soundbars, A/V receivers, DACs, and other digital audio equipment with a digital audio interface input port."

  • https://next.esphome.io/components/speaker/i2s_audio/#spdif-mode

And in case you missed it, the Sendspin component has now been merged to so included by default in the upcoming ESPHome 2026.5 release:

• https://next.esphome.io/components/sendspin/

  "The sendspin component adds support for Sendspin, a multi-room synchronized audio protocol. The hub manages the connection to a Sendspin server and distributes state updates to any Sendspin child components."

[fmsmuc]

this reference answers the implementation of generic_image in ESPHome but my question was - what is the the Sendspin "player_type.display",and how to use it in MA

[OzGav]

I don’t think you can

[fmsmuc]

If I cannot use it, why is this device type implemented at all? Wouldn't it make sense to link a display to a player—for instance, if you have a panel that controls cover art, titles, etc., but lacks its own audio output? Aside from that, according to the API, MA reports that it is capable of grouping.

[RealDeco]

player_type.display is if you have a device with display but no audio, i use that for a control device with display, so when in group with some speakers without display, sendspin won't try to sync audio with the control device too

[fmsmuc]

That's what I thought too, and the device also indicates that it can be grouped. However, the grouping fails.
#5479

[RealDeco]

all devices in the SendspinZero project has been update for esphome 2026.5.0b1:
https://github.com/RealDeco/SendspinZero

[Hedda]

in case you missed it, the Sendspin component has now been merged to so included by default in the upcoming ESPHome 2026.5 release:

• https://next.esphome.io/components/sendspin/
  "The sendspin component adds support for Sendspin, a multi-room synchronized audio protocol. The hub manages the connection to a Sendspin server and distributes state updates to any Sendspin child components."

FYI, ESPHome 2026.5.0b1 (Beta 1) is now available with beta changelog posted:

• https://beta.esphome.io/changelog/2026.5.0.html

  • https://github.com/esphome/esphome/releases

[cociweb]

Well, maybe I do something wrong, but I cannot put the ESP32 (with sendspin through HA) with other sendspin player into a synced group. Is it worth a FR?

[Nauttor]

Just want to add, I uploaded latest version of Voice PE firmware and i have the same result, Voice PE is not recognize as a sendspin device.
Device Voice PE
esp32-s3-devkitc-1
Firmware: 2026.5.2 (2026-06-04 16:16:13 +0200)

[cociweb]

A related bugfix here: music-assistant/server#4147 but it does not resolve the issue. We have a closed conclusion here: esphome/esphome#16745 (comment) but the real issue and workaround rests here: #5547 (comment)

[Hedda]

FYI, ESPHome 2026.5.0b1 (Beta 1) is now available with beta changelog

ESPHome 2026.5.0 has now been released with a family of Sendspin components included by default:

• https://esphome.io/changelog/2026.5.0/#sendspin-synchronized-multi-room-audio

  • Hub component (#15924) provides the basic connection and group state distribution.
  • Controller role and switch action (#15929) lets devices move between active groups.
  • Group media player platform (#15948) controls playback for a whole group (volume, transport, repeat, shuffle) without producing audio itself.
  • Media source platform (#15950) plays synchronized audio, with fixed and runtime-tunable delay compensation for downstream DAC/amp latency.
  • Metadata text and numeric sensors (#15969, #15971) report title/artist/album plus a polling track-progress sensor designed to drive displays.
  • Stutter reduction via sendspin-cpp v0.4.0 (#16178) marks decoder paths hot, allows player buffers in internal memory, and raises the player task priority above the websocket server. Combined with the new audio codec configuration, this enables real-time stereo Opus playback on a plain ESP32.

The new ESPHome 2026.5 release also contains major performance optimizations, including a modernized audio decoder pipeline, as well as a new (beta) ESPHome Device Builder web:

• https://esphome.io/changelog/2026.5.0/#introducing-the-new-esphome-device-builder-beta

[haldi4803]

I have zero Stutter anymore.
Everything works great.... Until now.