Multiple snapclients/-servers per host (like acables)?

[nis65]

Would it make sense to generalize the concept of snapclient similar to the acables ansible implementation?

I am just about to think how I will implement my multiroom solution in the new flat where it might make sense to run a snapserver on every host (i.e. you have multiple snapservers running in your network).

With a multiple snapclients implementation it would be easy to configure a snapclient on every host per snapserver in the network.

However, this would raise new issues of user interface: If all snapservers actually distribute music and every audio sink plays all snapclients at once, then you would hear in every room multiple audio streams at the same time (but each in sync with the other rooms :rofl:). So either you manually have only one snapserver actually play music (probably the the most user understandable way) or you need to control the volumes of each snapclient correctly on every snapserver :scream: .

In addition, this might multiply the network traffic substantially on my WLAN.

So I am not sure if this is actually a reasonable requirement...

OTOH, it would solve the audio distribution problem (e.g. you have an analog source in a different room or you connect your BT to a different sink). :thinking:

From a high level perspective, it is a question whether we switch sources or we run them simultaneously and whenever one source plays something, it can be heard (and when you are lucky, you have individual volume controls).

[nis65]

Well, in a completely generalized case, also multiple snapservers per host would be needed. With this, it would be possible e.g. to offer the bluetooth audio stream on one snapserver and the analog in on a different one.

Of course, this would take user experience one step further down the :rabbit: :hole: .

[Daenou]

I'm not sure if multiple snapclients per host / multiple snapservers solve more problems then it creates. For example, you'd need multiple apps / websites to control the different snapservers and volumes etc.

I think before implementing this in ansible it would be wise to do a manual POC if this is actually a solution you / we want to pursue.

I have thought about reconfiguring the snapclients via the built in snapcast JSON API but as far I can tell you can only configure clients' volumes and not the snapserver they'll listen to.

[nis65]

Fair enough. We might implement it in ansible when I actually have a manually proven use case. But not earlier. :smile:

Can we close this but keep somewhere in "low priority" "future enhancements" or so?

[nis65]

Use case not relevant yet. Reopen only if proven use case exists.

[nis65]

Idea for a use case:

Assume you have to different nodes in your network running a snapserver, snapA and snapB. All nodes have two snapclients installed, one pointing to snapA, the other to snapB.

When both snapservers are running snapweb, you only need two browser tabs to control the volumes of all clients.

As initially all clients are at 100%, you will hear the sound of both snapservers in all rooms. As long as you simply switch off your clients when you don't need them and once you have more or less assigned your snapclients to one or the other snapserver, I believe such a setup is "understandable".

[nis65]

Reopen as I actually have a use case for multiple snapclients on one host.

Will

• Run manually a 2nd snapclient on one of my raspis. If that works (should be easy),
• Create a separate branch and change the snapclient ansible implementation to support multiple client configs per host

[nis65]

Multiple snaclients is implemented in #25

[Daenou]

Functionality is in dev branch