-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snapserver protocol expansion to dynamically use source #1232
Comments
See MusicAssistant... it has everything what you want;-) |
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. |
Yes it's a controller for different protocols. Esp32 support is also possible. See here |
Not sure if I understand your use case correctly, there are two things that might help you:
|
Yeah, but that's just snapclient using the snap protocol :p |
But that still requires you to hardcode your multiple streams in your config file, right?
I saw that! That's also what music-assistant (ab)uses, but that requires you to know from a client which port to use
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? |
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. |
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 !)
|
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 |
@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 |
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:
***@***.***>
|
@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... ;-) |
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 :)
The text was updated successfully, but these errors were encountered: