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?