[REQUEST] SoundTouch Player Provider for Music Assistant (MA server)?

[Hedda]

Kind of off-topic but wondering if someone is interesting in developing a native SoundTouch Player Provider for Music Assistant? See:

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

FYI, Music Assistant (which is now owned and governed by the Open Home Foundation same as Home Assistant) is an combined free music library manager and integration platform implementation for supporting multiple music sources and player providers via "provider" modules. The Music Assistant server connects to to all type of different streaming services on one side and a wide range of different connected speakers as player providers in the other side. As such this server is the backend core of Music Assistant that keeps track of your music sources and player provider. The server can access multiple music providers and stream to multiple player types.

Music Assistant does however not yet support Bose's SoundTouch as a player provider (i.e. a client player). See:

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

and

• https://www.music-assistant.io/music-providers/

For a better overview of what Music Assistant is I highly recommend reading these two blog posts. Checkout:

• https://www.home-assistant.io/blog/2024/05/09/music-assistant-2/

and

• https://www.home-assistant.io/blog/2025/12/17/music-assistant-2-7/

This image can otherwise give you a good idea of input (music providers) and output (player providers) flows as an integration platform:

[treibbhaus]

Hi.
ST boxes are working with music-assistant.
With addons DLNA as well with Airplay.
I'm using the docker container.
BR Joerg

[Hedda]

I understand but that is not really what this request is about as this is not just asking for generic DLNA/UPnP or AirPlay support.

This is a feature request that is asking for a new dedicated native ”player provider” built-into the main Music Assistant server codebase explicit support for SoundTouch native control, (meaning with added functionality that can not be provided via MA’s generic DLNA/UPnP or AirPlay support). See:

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

A Player Provider inside the Music Assistent server application is the provider type that adds support for a 'target of playback' to Music Assistant. Bluesound, HEOS, Sonos, Chromecast, AirPlay and Spotify Connect are examples of such Player Provider in Music Assistent’s server codebase . All Providers (of all types) can be found in the music_assistant/providers folder. TIP: They have created a demo template/stub provider in music_assistant/providers/_template_player_provider to get you started. See:

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

[rmackinnon]

Agreed. While the built in DLNA support does allow it to produce sound, it doesn't provide native experience with those that are already used to the ecosystem. Same would go for linking the speaker as a bluetooth device. It's an amazingly great bandaid, that does fit some of the features, but the point here is to give (as @Hedda stated above) as native an experience as possible.

[TJGigs]

Im looking through discussions for info on generating a marge ID for a factory reset speaker after May 2026 and saw this thread.. chedck out the linkl below becuase I think this is what you are looking for. Im soon to release a new version that bakes in the cloud BMX registry handshake as implemeneted in soundcork and UberBose so you dont have to run that as a seperate process (its all working in my app but still trying to address assinging a margeID after may 2026 (this only effects factory reseted speakers) https://github.com/TJGigs/Bose-SoundTouch-Hybrid-2026

[Hedda]

@TJGigs Sorry but that it not what I am requesting. I believe you must have misunderstood how Music Assistent server works and most importantly what a ”Player Provider” component/module inside Music Assistent server is meant to do. First all posts in this thread where the concept is fleshed out in more detail and how the architecture for player provider inside Music Assistent server is structured:

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

FYI, I previously posted a reply to gmuth in that Music Assistant discussions forum where I explained what is actually wanted and needed, again please see replies and comments here:

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

Please see that whole Music Assistent discussion linked above for my request which is not only specifically asking for a native SoundTouch Player Provider component/module that is built-into Music Assistent server but also clearify that it should work similarly to all the other ”player providers” that are already available inside Music Assistent server codebase.

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

Note that they even have a template ”demo player provider” for reference, however due to a very recent refactoring of how their player providers should work if using multiple protocols I understabd that the best idea right now might be use use the Bluesound and HEOS player providers as references for this, see:

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

and

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

or start by look at their” demo player provider” for reference to get a more general overview of a default player provider should be structured:

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

To summerize, the main point with the Music Assistent server design is that you do not need make changes on the client side, as everything you needed to connect, stream and control a third-party smart speaker/receiver should be contained inside separate player provider components that are built-into Music Assistent server. So with their concept there is no need for external applications.

Think instead of the player provider as server-side translator that is part of the Music Assistent server. Each player provider is component module that all sits inside the core Music Assistent server and acts as an integration layer that allow Music Assistent server to speak nativly with different speaker APIs.
Users should not have to do anything with their speaker firmware (client side) as Music Assistant server should be made to communitate with them using their protocol, not the other way around.

So there is example a player provider for Google Cast inside Music Assistent server that allow it to connect/stream to Google Nest speakers. And there is a player provider for Sonos inside Music Assistent server that allow it to connect/stream to Sonos speakers, and so on.

FYI, there is by the way already a DNLA/UPnP player provider inside Music Assistent server, so it can also stream using that protocol but that is very limited and do not allow everything that the native SoundTouch protocol can do.
This is why the request is to make a native SoundTouch player provider inside Music Assistent server.

Again, there was also a recent refactoring in Music Assistent server that merged players concept tries to solve the scenario where players that support multiple protocols which previously showed as separate players will be now merged together and shown as only one player.

PS: Obviously both Music Assistent server and all its native player providers are written in Python.

[TJGigs]

Oh Thanks for Clarifying! I was thinking the other way... Yeah, my solution is not that. It instead just replicates the SoundTouch app and user experience bUT then calls Music Assistant (as the streaming brain) in the background to agonistically play back (via DLNA/AIRPLAY2) on the SoundTouch speakers’ whatever users have defined from their streaming provider in MA... Thanks again for your explanation so I can better undersatnd..Cool!

[Hedda]

Suggest that you and others interested in Music Assistent check out to the full discussion in the upstream Music Assistant discussions forum here -> https://github.com/orgs/music-assistant/discussions/4766

I realize now that better to only keep the discussion about this there instead of cross-posting as that is where the expertise hang out and if you and others here are not interested then the information posted there might be useful to someone else later if they would want to pick up that request from there.