Snapserver protocol expansion to dynamically use source

[oliv3r]

Currently, we have to define one entry in the configuration file for each source manually. For some things that works fine (airsync, spotify) however for the pipe/tcp endpoints this is rather odd. For simple setups of course it's understandable, but once you get into a 'family style setup' things get harder. E.g. lets say you have 4 potential sources, e.g. 4 people in a household. They all have their own preferences, sources, playlists etc. Lets also say we have a few client groups. e.g. 1 per user/room, one shared for livingroom + kitchen, 1 for shared livingroom and patio.

Sometimes, people want to listen to their music just in their room. Sometimes people want to listen to their music throughout the house. Sometimes there's a different mood on the patio and in the living room.

When connecting a client to the fifo/socket, It would be nice if it would dynamically show up as a new source. If the source where to send some metadata (source-name, maybe even an UUID) that would be enough. Everything else could function as it does right now, but without the need to specify unique sources for each player.

Note, that I very much realize this also means unique instances of frontends for each of those sources, but that could be arranged if needed, e.g. a frontend could be made smarter (e.g. each 'UI' gets its own session or a 'create session' like button).

This would certainly bring snapserver to the next level :)

[DerPicknicker]

See MusicAssistant... it has everything what you want;-)

[oliv3r]

You mean https://github.com/music-assistant/server ?

That does look interesting, because of has ;)

however, what is the protocol? is it snapcast compatible? where is the esp32 client? Or an openwrt client. those are the things I want :p

I do see very cool that they have an integrated python simple snapserver. so that's pretty interesting.

[DerPicknicker]

Yes it's a controller for different protocols. Esp32 support is also possible. See here

[badaix]

Not sure if I understand your use case correctly, there are two things that might help you:

1. The meta stream that combines several streams into one and plays the active sub stream, ordered by priority.
2. You can add and remove streams using the JSON RPC API. I think I will restrict this in future, because you can add process streams, executing arbitrary commands
3. I have a stream API in mind, some small c-library, that can serve as stream source, i.e. the snapserver can request PCM chunks, as well as the sample format and meta information, like stream source name and information about the current title, ... But I'm not sure if anyone would make use of such a lib. It would be great for a Snapcast gstreamer sink. This library would of course also register itself at the server as a stream source.

[oliv3r]

Yes it's a controller for different protocols. Esp32 support is also possible. See here

Yeah, but that's just snapclient using the snap protocol :p

[oliv3r]

Not sure if I understand your use case correctly, there are two things that might help you:

1. The [meta stream](https://github.com/badaix/snapcast/blob/develop/doc/configuration.md#meta) that combines several streams into one and plays the active sub stream, ordered by priority.

But that still requires you to hardcode your multiple streams in your config file, right?

2. You can add and remove streams using the [JSON RPC API](https://github.com/badaix/snapcast/blob/develop/doc/json_rpc_api/control.md#streamaddstream). I think I will restrict this in future, because you can add process streams, executing arbitrary commands

I saw that! That's also what music-assistant (ab)uses, but that requires you to know from a client which port to use

3. I have a stream API in mind, some small c-library, that can serve as stream source, i.e. the snapserver can  request PCM chunks, as well as the sample format and meta information, like stream source name and information about the current title, ... But I'm not sure if anyone would make use of such a lib. It would be great for a Snapcast gstreamer sink. This  library would of course also register itself at the server as a stream source.

I'm thinking something like too; but in the end; what you expect as a user to be able to do is to simply connect to a tcp-port, and that after connection you get your own stream. E.g. like the telnet server works (and every other tcp client/server :p). That would 'fix' that issue. No c-library or anything needed.

So then I wonder what the reasoning was behind the current tcp-server 'restriction' to only a single client?

[SantiagoSotoC]

You mean https://github.com/music-assistant/server ?

That does look interesting, because of has ;)

however, what is the protocol? is it snapcast compatible? where is the esp32 client? Or an openwrt client. those are the things I want :p

I do see very cool that they have an integrated python simple snapserver. so that's pretty interesting.

We (Music Assistant) don't have a snapcast server in python, what we have is snapserver running in docker and an integration with the snapcast api.
Our port lookup is on snapcast server, the connections to the clients are made on the standard ports, 1704 and 1705 and that is taken care of by the snapserver.

[oliv3r]

Right! I admit I was just briefly reading the code and it looked like ;) So music assistant is a 'replacement'/counterpart of mopidy really then. Makes sense too, not doing the server bit yourself. I've been hacking a bit on snapserver, but a bit of yak shaving happened of thing I needed. I wanted to see if I could make the stream reconfigurable. Or at least, reconfigure it after object creation. Its not ideal, but its how the code just is at the moment. With reconfigurable object, I then thought to inspect the first packet (not all, that would be computationally expensive) and let the sender set the required parameters. By rejecting unsupported features (and thus closing the connection) a stream has some control of what/how to send. If the first packet is no config packet, its treated as audio as before. With that in place however, we can then easily support multiple incoming connections. But first gotta test if my changes actually work !)

[letshin]

I admit that i'd be interested in this too. We have a newborn so for example it would be nice if I could select a white noise playlist and just play that in the room while also listening to my music in the living room (they are all connected to the same snapserver). Am I misunderstanding or is this the idea you are trying to implement as well? @oliv3r

[DerPicknicker]

@letshin .. this is already possible with MusicAssistant. Each player can play individually or the same as a group. Only one snapserver is needed. Which is already included in MusicAssistant

[letshin]

Ok, is there an API I can use with the HA module and node red? Also is it possible to use it with HA docker instead of HA core? How about the music library? Mopidy eg arranges this previously. How does Music assistant handle it please? Is it just an explorer window where I select the folder with my songs? Cause this is what HA's default option does at the moment.

…

On Wed, 31 Jul 2024, 10:36 DerPicknicker, ***@***.***> wrote: @letshin <https://github.com/letshin> .. this is already possible with MusicAssistant. Each player can play individually or the same as a group. Only one snapserver is needed. Which is already included in MusicAssistant — Reply to this email directly, view it on GitHub <#1232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJTVK5YYHZN275RTIBZQKFTZPCVYFAVCNFSM6AAAAABHJYMH2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQGA4DSNJQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[DerPicknicker]

@letshin ...

You can run it as stand alone docker container.

If you install the MusicAssistant integration inside HA you can build automations like normal entities.

MusicAssistant supports several music sources: file-system, Spotify,samba, tidal, YouTube music.

It's a music server and displays your media nicely. I like it more than Mopidy because it looks more modern... ;-)