Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

RompR multi user setup #36

hcanGuido · · author
#1

Hello,

first of all, I would like to say thank you. I use RompR for several years, an I love it.
Now I want to let my family be a part of it and wonder what would be the best way to do this.
I would like to install snapcast to hear music in every room. But I`m not suhre how to set up the following scenario:

Every member of my family should get his own RompR instance to set his own ratings, favorits, playlists...
But I would like use music store and one mySQL Server for all of them together.
RompR should be accessed from the personal mobile but also from a browser, running on wall mounted android devices, which now present the home automation (fhem) web interface.

So the e.g. my son should go to the living room and start his music over the wall mounted tablet or his mobile and give his personal ratings.

Any help would be appreciated.

Thanks in advance

Guido

  • replies 19
  • views 2.8K
  • likes 0
#2

Well now. That is a complicated problem.

First of all, Rompr was never designed as a multi-user application. Literally the only way you can even begin to achieve what you want is to have a separate database for every user, and a separate installation of RompR for every user, and a seperate player in every room. So you can do it with one webserver and one sql server but you're going to have to configure multiple rompr installations and I can't even imagine what might happen if two people tried to control the same player from two different rompr installations at the same time... it would not end well!

Then you want to add Snapcast into it as well! Well, I admire your ambition but I honestly have to say that there isn't a neat way to do it and I suspect you may be letting yourself in for a world of difficulties if you attempt it.

One player in every room - great. Snapcast - great. Combining the two - difficult. Doing all that and having multiple rompr installations - next to impossible.

hcanGuido · · author

Hello Mark,

thanks for your quick reply.

I have no experience with snapcast until now, but I wonder if I could not solve the problem as follows:

(Assuming we have 4 family members.)

1 fileserver which holds the music files
1 database server with 4 users and 4 romprdb's (one for each user)
4 mpd instances (one for each user)
4 RompR instances (one for each user) each one is connected fix to one mpd and to "his" romprdb
1 snapcast server configured to manage 4 sources (the 4 mpd´s)

In every room one RPi configured as snapcast client or, the cheaper way, less RPi´s, which run more than one snapcast client each connected to it`s own usb sound card, if this is possible. Then every client/sound-card combination is assigned to one room.

When I understood the documentations correctly and snapcast is able to provide different sources at the same time (I found no explicit answer to this), I have two possibilities:

  1. Every client has his own group. Then every user could assign in his RompR instance the source from his mpd to this group.

  2. I create 4 groups (one for each user) and assign the user's source to his group. Then the user could use his RompR Instance to dynamically add the "room client('s)" where he wants to hear his music, to his group.

Should this go right?

Thanks in advance

Guido

#4

It's an extraordinary and ambitious thing to attempt I honestly don't know if it'll work because it's too complicated to get my head around!

1 fileserver which holds the music files
1 database server with 4 users and 4 romprdb's (one for each user)
OK so far

4 mpd instances (one for each user)
I don't know if you can have 4 mpd instances running on one host. They can't run on different machines because snapcast uses a FIFO.

4 RompR instances (one for each user) each one is connected fix to one mpd and to "his" romprdb
OK

1 snapcast server configured to manage 4 sources (the 4 mpd´s)
4 streams can theoretically be done. You will definitely need to put the FIFOs on a RAMdisk in /tmp

In every room one RPi configured as snapcast client or, the cheaper way, less RPi´s, which run more than one snapcast client each connected to it`s own usb sound card, if this is possible. Then every client/sound-card combination is assigned to one room.

I don't know if you can run more than one snapclient on a machine. Also I would very strongly advise against using mutliple USB DACs on a Raspberry Pi, and absolutely definitely not with long USB cables. You'll draw too much current and the Pi will become unstable. USB DACs on Pi can be problematic for other reasons too - there is a lot of electrical noise on the USB ports of a Pi and you can hear it through the speakers. For snapclient, a Pi Zero W with an of the DAC HATs makes a decent client. Or if you want to be more audiophile, a 3B+ running something like a Pi DAC Pro.

Every client has his own group. Then every user could assign in his RompR instance the source from his mpd to this group.

I create 4 groups (one for each user) and assign the user's source to his group. Then the user could use his RompR Instance to dynamically add the "room client('s)" where he wants to hear his music, to his group.

What you're talking about is creating 4 streams on the snapserver. Then to play music someone has to assign a stream to their player and then assign rooms to their stream. That does sound right but I can't really get my head around it. Are you sure you're not getting carried away with ideas? 4 players is complex enough but you're creating a 4x4x4 matrix of possibilities and in order to listen to music a user has to configure that matrix every time. Good luck with that! :) I don't think Rompr's UI is the right tool for that if I'm honest, it'll be too complex and nobody will use it.

I mean please try, and tell me if it works, but I think you're a bit crazy! :)

hcanGuido · · author
#5

I don't know if you can run more than one snapclient on a machine.

That´s no problem. Then I will use one RPI for each room

I don't know if you can have 4 mpd instances running on one host.

I`m not familiar with docker, maybe that´s a possibility? Otherwise I will use 4 vms on my XEN server.

Then to play music someone has to assign a stream to their player and then assign rooms to their stream.

I have no experience with RompR and snapcast, but isn`t it so that RompR saves the selected stream?
If the stream is set up once for the user, he can use it the next time out of the box and has only to select the room where he wants to here music. Mostly the selected rooms would not change, so the this selection is always there when the user logs into is RompR next time.

I will do my best and promise to tell you the result.

I`m not familiar with docker, maybe that´s a possibility? Otherwise I will use 4 vms on my XEN server.

VMs won't work. You need only one instance of snapserver, and mpd has to write into a FIFO, meaning all mpd instances need to have access to the root filesystem where snapserver is running. (There is a TCP sink too but that has a whole load of other issues). Hence you need 4 instances of mpd all running within the same root OS.

However, reading your last post, I think for sure you are overcomplicating this. Sanpcast is for playing music in multiple rooms simultaneously - one player, one source, multiple rooms. It doesn't sound like that's what you want. All you need is one player for each room, and then the user simply selects a player for whichever room they're in. The player can even be selected by a parameter in the URL so you could have a simple bookmark - something like 'Guido - Kitchen' that links to 'http://ip.address.of.rompr/guidos_rompr?currenthost=Kitchen' would give you immediate access to your rompr, connected to the player in the Kitchen.

hcanGuido · · author

Hello Mark,

thank´s for your help, answers and your ideas. I will think about it, try something and if I have a result or a question come back to you.

Thank you very much!

Guido

hcanGuido · · author

Hello Mark,

today I finally had time to put my hands on my multiroom configuration.

So far I have the following test configuration up and running (at this time with 2 users & 2 clients):

One VM which holds two mpd instances, the snapcast server and two RompR players.
RompR1 is connected to mpd1 (for test user1) and RompR2 to mpd2 (for test user2)

I gave each fifo's the name of one of test users.

Each group contains exactly one client. Both, the group and the client, have the name of the room where the client is installed.

With this configuration a user is able to use RompR as if he was a stand alone user (playlists, ratings, etc.), although if he shares the music files with the other users.

If one wants to play his music in a specific room, one can choose his mpd stream for that room.

Since a few hours the setup is running fine.

I now have to connect the external database and file-server which holds the music archive.

If everything is running fine, I would post my config files if you are interested in.

There are two things that are not so nice, maybe something can still be done:

  1. If I change the stream on RompR1 it could take up to round about one minute until RompR2 updates the status. Would it be possible to change the interval?

  2. Do you think it would be possible to make the snapcast config visible in the main window? So that one could choose groups and streams without having to go to the settings menu every time?

Thanks in advance

Guido

#9

Each group contains exactly one client. Both, the group and the client, have the name of the room where the client is installed.

If each group contains only one client then I still don't understand why you are using snapcast? The entire point of snapcast is that groups contain multiple clients for simultaneous synchronised output in multiple rooms. If all you want is one client per room then you can have that using multiple mpd players without the added complexity of having to choose streams. You can simply have a shortcut or bookmark that automatically selects the user and the player/room with no need to select a group or a stream at all.

If I change the stream on RompR1 it could take up to round about one minute until RompR2 updates the status. Would it be possible to change the interval?

In theory I could, but it's intentionally set at one minute to reduce the load on the snapcast server. In my testing, polling it too often resulted in drop outs and loss of sync between rooms.

Do you think it would be possible to make the snapcast config visible in the main window? So that one could choose groups and streams without having to go to the settings menu every time?

Firstly, where would I put it? The UI is already crowded. Secondly as I say, I think what you're created is fun and interesting but it's an extremely niche and overcomplicated solution to a problem that appears a lot simpler than you are making it.

Mark

hcanGuido · · author

If each group contains only one client then I still don't understand why you are using snapcast?

As I wrote before, I see two possibilities:

  1. Every client has his own group. Then every user could assign in his RompR instance the source from his mpd to this group.

  2. I create 4 groups (one for each user) and assign the user's source to his group. Then the user could use his RompR Instance to dynamically add the "room client('s)" where he wants to hear his music, to his group.

Actually I choose the first possibility.

The entire point of snapcast is that groups contain multiple clients for simultaneous synchronised output in multiple rooms.

From the snapcast homepage:

The encoded chunks are sent via a TCP connection to the Snapclients. Each client does continuous time synchronization with the server, so that the client is always aware of the local server time. Every received chunk is first decoded and added to the client's chunk-buffer. Knowing the server's time, the chunk is played out using a system dependend low level audio API (e.g. ALSA) at the appropriate time.

As you see, there is no need for putting the clients in the same group to get synchronised audio.

And I don´t understand why you say:

I think what you're created is fun and interesting but it's an extremely niche and overcomplicated solution to a problem that appears a lot simpler than you are making it.

Example:
I am sitting in my buro and listen to my music.
Lets assume I want to make a break.
First I go to the kitchen. If I want to hear my music there, I use e.g. RompR, choose the kitchen and set my stream as source for the kitchen. Then I maybe go to the livingroom and do the same.
Now my music is played in my buro, the kitchen and the livingroom - synchronized!

What, in this solution, is more complicated, than select the group with my stream and add the client from which I want to here my music to this group, like you said?
With my solution I can do everything within RompR. But, as far as I can see, there is no possibility to add a client to another group in rompr. So, for your solution, I always need a second app. Right?!?

Form my understanding the only advantage adding a client to a group is to have a centralized volume and mute control. But that I can also do within RompR which I use anyway to choose my music.

#11

Well, I see what you're achieving, and yes you do need snapcast. It does still seem to me to be very complicated - the process of having to choose a rompr instance and a player and a group and a stream just to listen to some music... I think most people would simply opt for something easier to use, like a Sonos system... :) I know I would. It's something where I think your basic setup is sound, but the UI in Rompr is really not designed to do it. I don't think just 'making the controls easier to get to' is right solution - the right solution is to change the way the controls work to make your very complicated user/room/stream selection process easier. But that's not something I'm interested in doing right now.

hcanGuido · · author
#12

Sorry, but i have a feeling that you don't understand me properly.

What do you do if you use to use RompR?

Right, you put it´s address in a browser, or you click on a bookmark.

For my installation each family member has his own bookmark.

I´m married and you can beleve me, I know what WAF (woman acceptance factor) is.

With the choosen solution my wife opens the RompR bookmark in her browser, and plays her own playlist like one does who has no multiroom solution.

And then, if she want´s to hear her music in the livingroom, she simply clicks on preferences and changes the stream in the group
livingroom to the source with her name. That´s all, no magic, not complicated.

If I would integrate snapcast in the homescreen of RompR with the possibility to toggle this on and of, do you see the possibility that would you merge this?

#13

I think it's possible there is a communication problem - your English is excellent but there are a lot of terms being used and I am still struggling to really get my head around this use case :) The way you describe your wife using it, I am definitely not picturing it like that in my head :) No matter, I'm glad it works for you.

I´m married and you can beleve me, I know what WAF (woman acceptance factor) is.

Lol. I'm glad. To be honest, my acceptance factor is probably worse, I hate anything that needs more than 3 clicks or needs too much configuration :)

If I would integrate snapcast in the homescreen of RompR with the possibility to toggle this on and of, do you see the possibility that would you merge this?

I would definitely be interested in that. I hate writing UIs :) One thing you could do is write it as an info panel plugin, then you have all the space of the information panel to use. I'd love to see something that allows you to do what you want while simplifying the process somehow. It's possible to make info panel plugins open automatically when you open rompr, so that might work - not so great on a phone though, but then I don't see where it could fit on a phone anyway.

If you base anything you do on the develop branch, I'll look at any pull request, and I'm happy to answer questions to get you started.

hcanGuido · · author
#14

Hello Mark,

thank you for the positive answer, your offer for help and the time to get your head around my needs.

My last php experience was with version 4, so i will first try to get the rust off. ;-)

As you can see it took a few weeks to find the time to test the snapcast setup and I think it will take even more time to get this job done especially because I´m involved in many other project at this time.

I will be back when I have done the fist steps.

Thanks in advance.

Guido

#15

No problem, whenever you like. I usually get more involved with RompR in the winter when the nights are long... You'll mainly need to work in Javascript/JQuery to implement anything in the RompR UI.

hcanGuido · · author

That fits me well, for now I´m mainly working on our swimming pond (in my spare time)... :-D

#17

If you're interested in looking at the develop branch on github, I've made some changes to the snapcast UI.

Firstly, all clients will now update immediately if something changes. Secondly I've moved some things around a little to make selecting groups and streams a little easier. Be interested to know what you think.

hcanGuido · · author
#18

Hello Mark,

I´m very very sorry that I was absent for so long.
The last months I spent every second of my spare time in my garden.
After our last conversation I did not expect, that you take the time to solve my request.

Your solution is absolut incredible. I could not wait and it took some time to get my test devices up and running again, but then I didn`t trust my eyes.

When I change the source of a client, RompR shows the result even before the client plays the music!
I have not had time yet to see how you did this, but it is awesome!

The changes you made to the ui are also fantastic. The selecting of groups and streams is very nice.

For my use case the stream of each group would probably change often. So it would be nice to have direct access to something like the snapcast section of the settings menu albeit for me it is not nececery to see the group members (clients).

I would have about 16 groups which should be visible in a good structured ui.
I think that I would be able to take your code an change it for a info panel plugin maybe with some checkboxes so everybody can choose the elements which are important for his use case.

I hope that I find the time to make the changes before the weather is good again and I must work in the garden to complete the paradise for my kids... ;-)

Thanks again. I will be back as soon as possible

Guido

#19

No problem Guido, after the year we've all had every second outside is precious :)

I found that snapcast has a JSON-RPC API that I can connect to using a websocket, this allows me to react to messages sent to me by snapserver, instead of me having to poll. So it should all update instantly.

The main problem really is simply finding somewhere in the UI to put all this stuff without making a really messy interface :) It's only one click to open the settings menu (or the volume control menu on a phone) - info panel plugins take more clicks to open, especially on a phone. Be interested to see if you come up with a clever solution.

hcanGuido · · author
#20

If I look at vanishingpoints.net it seems that you have enough of these seconds too... ;-)

Realy great work!