Sending announcement to multiple players | Music Assistant | Page 1

fiery rock Apr 12, 2026, 5:58 PM

#

What's the best strategy to send announcements to multiple players? I see that when I use the HA action tts.speak and define multiple MA players targets, that each player gets its own TTS_proxy URL instead of 1 cached responsed being played on all players. Result is that announcements are heavily out of sync. If I use the MA announcement action, I have to provide a URL to be played - unfortunately I have no idea how to retrieve a URL for a TTS text. I think I remember there was an action to not speak a TTS message but rather retrieve the URL - but I can't find it anymore.

I use this for announcements that should be cast to occupied areas in my home - so it's dynamic and I can't use pre-defined groups. All devices are cast devices. Anybody has similar experiences or tips on how to improve the user experience?

fiery rock Apr 15, 2026, 8:04 PM

#

Really no one?

blissful oracle Apr 15, 2026, 8:40 PM

#

You could try to setup a group for this within MA

#

It depends on the player types etc. how well it would work

fiery rock Apr 16, 2026, 5:35 AM

#

As I mentioned it is dynamic which room is occupied and I can't use groups.

blissful oracle Apr 16, 2026, 7:00 AM

#

To what players are you trying to send it ?
Chances are low that you will get this in sync anyways

fiery rock Apr 16, 2026, 8:06 AM

#

Nest Audio and nest mini. I don't need them to be in sync on a sub-second basis. But when I send to multiple devices at the same time, it sometimes takes 10s until one speaker plays the announcement and then another 2 seconds for the next one. Previously I sent announcements to the cast entities in HA not the MA entities for those cast entities. That was much faster.

#

Maybe I'm doing it wrong and should rather send to the HA cast entities but then I think the announcement settings in MA won't be taken into consideration. I also wanted to use the MA action for announcements but they only work for URLs and I don't know who would use URLs to play an announcement (unless using pre-recorded announcements).

blissful oracle Apr 16, 2026, 8:12 AM

#

I will have to reproduce this but as far as I'm aware these announcements are processed in parellel. Unless they are somehow already playing in a group ?

fiery rock Apr 16, 2026, 8:16 AM

#

They are not playing in a group. I have a suspicion that this might have to do with my TLS setup that is always an issue with voice in HA because the external TTS proxy is used instead of the internal one.

#

Could you please let me know what is the expected way of sending announcements to MA speakers? It's not clear to me which way is the expected one.

junior thorn May 16, 2026, 4:38 AM

#

tts announcements i find to be a lot faster (and can be interrupted) when using HA media player instead of sendspin
example, my fridge talks when holding the door open too long and the second i close it say "thank you", even if in the middle of speaking. with sendspin the thank you comes after it's finished complaining..

fiery rock May 16, 2026, 9:17 AM

#

But then the announcement params inside MA are ignored. Also: when music is playing, will media be resumed after the announcement?

#

Just tested. It will not. So frustrating right now. 3 ways of sending TTS to a MA player and all of them are flawed.

sending via HA cloud_say action to MA player uses announcement settings from MA and resumes playback but is extremely slow.
sending via HA cloud_say action to corresponding Cast device in HA will not use announcement settings from MA and won't resume playback but it is really fast.
sending via MA announcement action only works with URLs, not a TTS message. So useless unless you have some way of obtaining a TTS URL. I have not tested how fast it is but I assume it will respect announcement settings in MA and resume playback.

junior thorn May 16, 2026, 5:13 PM

#

fiery rock But then the announcement params inside MA are ignored. Also: when music is play...

in esphome i use mixer so no, music will not be stopped, it will play together with announcement

#

tts is usually louder than music so i haven't even applied any ducking

fiery rock May 16, 2026, 6:00 PM

#

That's good and I hope that this will come to sendspin if possible. I use Nest audios/minis, so I have to wait for that. For now I use a script for TTS that determines if the player is playing and if it is not, to use the cast entity instead so at least those TTS messages are not delayed.

blissful oracle May 16, 2026, 6:01 PM

#

How much delay are you experiencing?

fiery rock May 16, 2026, 6:15 PM

#

It varies. Sometimes 3 seconds but sometimes up to 10 seconds. Also takes a bit of time until the playback resumes (that is rather consistent and around 2 seconds after playback of the announcement).

#

The more speakers I send an announcement to, the worse it gets. That might be because the SBC I am running HA and MA on is a bit underpowered. I will replace that in the near future with a more modern one - maybe that will already solve the issue. Then again my subpar machine might be a good indicator for something that could take some tweaking. It's the same machine that 2 years ago led me to complain about speed in Assist for specific languages which led to Mike et al introducing a caching system and optimizations in intents that sped this up drastically.

#

@blissful oracle I can try to get some hopedully meaningful debug logs. Let me check that tomorrow.

young pond May 16, 2026, 7:01 PM

#

@fiery rock https://www.home-assistant.io/integrations/tts/ this tells you how to get the URL for a tts message using the REST API. There's a mistake in the sample curl command, "engine_id" should be "tts.amazon_polly" there, not "amazon_polly".

Home Assistant

Text-to-speech (TTS)

Instructions on how to set up text-to-speech (TTS) with Home Assistant.

#

That example is handy, it'll generate the sound file for you, then return the URL

fiery rock May 16, 2026, 8:12 PM

#

young pond <@602406962902073371> https://www.home-assistant.io/integrations/tts/ this tells...

Yeah I know but I don't want to create a long-lived token for something as uncritical as a TTS url. Had hoped there would be a better way.

fiery rock May 17, 2026, 2:48 PM

#

@blissful oracle So I have tested this quite a bit today with 2 Cast players (both Nest Audio, both set to native protocol in MA). Logs didn't help that much, even when set to verbose. Here's what I found:

#

Scenario 1: both media players are playing separate radio streams

announcement sent via tts.cloud_say action to both players:
It takes 10-14 seconds for the announcement to play. The radio streams where interrupted ~1.5s after starting the action call. Looking at the logs the announcement URLs for both players obtained from HA cloud are different - although I enabled caching in the action call. (will explain later why)
announcement sent via tts.cloud_say to both players but with 2 parallel action calls (so not providing both entity IDs in 1 action call):
I get the same result. Takes again 10-14 seconds for TTS to start playing and both players receive different Nabu Case TTS Proxy URLs.
announcement sent via music_assistant.play_announcement action with a previous TTS Proxy URL to either one or both of those players
The TTS will again be very delayed but both players use the same URL at least. If I rewrite the URL to my internal HA URL, this is slightly faster - but not significantly. When sending this way to both players, the announcements play in sequence, never in parallel.

#

Scenario 2: only 1 media player is playing a radio stream

announcement is sent via tts.cloud_say to the player playing the radio stream:
It takes around 2-3 seconds for the TTS to play. I feel this is somewhat acceptable given that it uses the external URL.
announcement is sent via tts.cloud_say to the player NOT playing the radio stream:
Same as (1)

#

Explanation of cache issue

I assume this is because of my HA setup. I use TLS on my internal HA server (no reverse proxy, the HA-provided TLS feature). It is known that HA in those cases will always use the external URL (= Nabu Casa cloud), because (I think) it is assumed, that when a user is running internal TLS this must be self-signed which won't work with Cast. My internal cert is NOT self-signed though, it's a publicly valid one - nevertheless HA behaves that way. Because of that, I had to take control of my VPE and rewrite the announcement URLs from https://<redacted>.ui.nabu.case/api/tts_proxy/<hash>.mp3 to https://<my_internal_server>:8123/api/tts_proxy/<hash>.mp3 to get quick TTS responses. Something I unfortunately can't do with MA - unless I use the REST API as proposed earlier.

fiery rock May 17, 2026, 4:09 PM

#

So in essence - it definitely is a performance issue on my machine, since with only 1 radio stream active, announcements work well. The MA announce action is the worst way to send announcements as it will play announcements sequentially and never in parallel. The usual problem with HA never using a cached internal TTS Proxy URL when the internal HA server is TLS-enabled, is once more (just like with Assist) a bad implementation IMHO and unfortunately with MA can't be solved as using the REST API to get an URL, then rewriting that to internal and sending it with the MA announce action is still meh because of the sequential playback.

#Sending announcement to multiple players