AutoConfig vs. meta

[gregorij89]

Hi, this is more a question that an issue. Firstly big thanks to you and your awesome job. I am implementing the same use case as you, but leveraging docker for that. So I am not using your code directly, but it is a huge inspiration for me.

Now to the question. As snapcast-autoconfig seems to be abandoned, I don´t want to build up my solution on it. I am playing around with a python-snapcast library to duplicate the behavior but so far I am in the PoC phase. But today, I´ve got another idea. Why one needs autoconfig, when snapcast offers meta sources? The theory: I want to have priorities on the sources of the sounds and also on the logical zones. Meaning airplay has the highest priority, then plexamp, then mopidy. Zone-wise, "local" has the highest priority, then parts of the house and then the whole house. So why one shouldn´t configure one meta stream for each physical device (each snapcast client) in the way meta:///local-airplay/local-plexamp/local-mopidy/mastersuite-airplay/mastersuite-plexamp/mastersuite-mopidy/house-airplay/house-plexamp/house-mopidy? It should work, does it? The downside is, that even "local" sources have to be streamed through snapcast, but it doesn´t bother me so much. What do you think?

Second question I have is about multiple shairport-sync instances. How do you configure them? My snapserver.conf file containing these lines:

stream = airplay:///usr/local/bin/shairport-sync?name=house-airplay&devicename=House&port=7000&params=--configfile=/config/dum-shairport-sync.conf
stream = airplay:///usr/local/bin/shairport-sync?name=mastersuite-airplay&devicename=MasterSuite&port=7001&params=--configfile=/config/mastersuite-shairport-sync.conf

But in iOS, when I want to select the device for streaming, I can see only one of these two. And more strangely, if I connect to them, they are interchanging. So I am seeing a device called MasterSuite, but once I connect to it, it changes to House and streams to house pipe. Also the name in iOS changes to House. Then I disconnect and connect back to House. In that moment, it change back to MasterSuite and streams to mastersuite pipe.

I know these questions are not directly related to the code you are providing, but still, I am hoping for an answer :).

[markferry]

Now to the question. As snapcast-autoconfig seems to be abandoned, I don´t want to build up my solution on it. I am playing around with a python-snapcast library to duplicate the behavior but so far I am in the PoC phase

My assumption was that most would want to implement the automations using HomeAssistant - which between MQTT and the snapcast integration is relatively easy to do if you're already using HA.
multizone-control.py is also just a PoC.

So why one shouldn´t configure one meta stream for each physical device (each snapcast client) in the way meta:///local-airplay/local-plexamp/local-mopidy/mastersuite-airplay/mastersuite-plexamp/mastersuite-mopidy/house-airplay/house-plexamp/house-mopidy? It should work, does it?

Meta streams do work, and I use them to assign priorities to my streams in the same way - but more as a way to keep the music gapless.
(Crossfade between meta streams might be fun...)

I think meta streams are best suited to things like the Announcer stream where I want to interrupt then return to whatever was playing afterwards.

Meta streams are also frustrating for users. They can't figure out how to get a zone to shut up if you have multiple streams going.
They stop one but then the other takes precedence and music keeps playing!
Hence the mqtt and multizone-audio-control service that stops other streams when one starts.

Note I recently switched to librespot-java (which is so much better!) - but multizone-audio-control is broken for Spotify on that branch.

Second question I have is about multiple shairport-sync instances. How do you configure them?

I see you've got snapserver setting the port and devicename. That should be sufficient so I can only guess that perhaps shairport-sync config is getting in the way (are the settings also different in the shairport-sync.conf files?), or you've got old processes hanging around.

If I look systemctl status snapserver I can see, for example:

   CGroup: /system.slice/snapserver.service
           ├─25137 /usr/bin/snapserver --logging.sink=system --server.datadir=/var/lib/snapserver
           ├─25143 /usr/local/bin/shairport-sync --name=Study --output=stdout --use-stderr --get-coverart --configfile=/etc/multizone-audio/shairport-sync.study.conf --metadata-pipename=/tmp/shairmeta.25137.5106 --port=5106
           ├─25144 /bin/bash /etc/multizone-audio/librespot-api.sh 24806 39806 0 /mnt/md6-media/music/metadata/librespot-java Study
           ...

(Snapserver generates that metadata-pipename automatically, I don't set that.)

I can also see the open ports reflected in netstat:

sudo netstat -pntl | grep 5106
tcp        0      0 0.0.0.0:5106            0.0.0.0:*               LISTEN      25143/shairport-syn 
tcp6       0      0 :::5106                 :::*                    LISTEN      25143/shairport-syn 

And of course check that they're not firewalled.

If that doesn't help then avahi-browse -a from avahi-utils might help see what's being advertised...

[gregorij89]

Hi, thank you for the response and also I am sorry for the late reply. I haven´t had much time to play around with multiroom audio last two weeks.

As for the controller, I am using openHAB for my home setup. And there is unfortunately no binding for the snapcast. But, I understand your point about the zones and sources and the possibility of user confusion. But that I can cover with starting/stopping the sources from OH. Mopidy, shairport etc. are capable of MQTT integration and that is all I need. The only thing I was not able to do is to transfer snapclients across zones. And that is achievable via meta streams.

Still to that one question. It is pretty straightforward to stop the source when another source with higher priority starts playing in the same zone (eg. shairport overrules mopidy). But what if a zone with higher priority starts playing? Take an example: Mopidy stream is running in the Whole House zone. Then, someone else starts playback in Mopidy for zone First Floor. In that case, all clients on the first floor, that are currently playing the Whole House stream should abandon that stream and start playing First Floor. But clients on other floors are still playing Whoule House stream and it shouldn´t be stopped. So in metastream config, the higher priority First Floor Mopidy stream takes precedence. In the case of config script, one should remove clients on the first floor from the Whole House stream and assign them to the First Floor stream. And now, how your setup behaves, when one stops the playback on the First Floor stream and the Whole House stream is still running? In the case of meta streams, clients on the first floor fall back to the Whole House stream. And I think that is the correct behavior.

For the shairport sync question. In the conf files, I´am just specifying MQTT connection and log files location. I´ve checked the listening port and both are registered to shairportsync processes with different pids. Also browsing mDNS shows that both are advertised with the correct ports. What caught my eye is the naming of the advertising service. They are advertised as 71E7B827342E@MasterSuite and 71E7B827342E@House. Reading this post I have the feeling, that it is not possible to have multiple instances of shairportsync AirPlay2 on one IP address. From what I understand, AirPlay2 clients (eg. iPhone) can´t handle that. If it is true, I would have to spin up separate docker container for AirPlay2 in every zone and assign it direct IP (macvlan network is a friend here) and connect it to the snapcast as another fifo file. Basically similar setup like with mopidy. Or reconfigure shairportsync to act as an AirPlay1 target.

From your outputs, it seems you are running just one instance of shairportsync in snapserver. Also port 5106 is not a standard one for AirPlay2 (7000 is). Could you please confirm, that you are able to run multiple shairport instances in AirPlay2 mode directly from snapserver and succesfully connect to them?

[markferry]

For the shairport sync question. In the conf files, I´am just specifying MQTT connection and log files location. I´ve checked the listening port and both are registered to shairportsync processes with different pids. Also browsing mDNS shows that both are advertised with the correct ports. What caught my eye is the naming of the advertising service. They are advertised as 71E7B827342E@MasterSuite and 71E7B827342E@House.

Aha. I didn't see that you were doing AirPlay2. Awesome!

There's discussion about airplay2 multiple instances which is a little later than the one you linked and it seems to hinge on the mDNS DeviceID.

Seems you need both general.airplay_device_id_offset and general.port settings.

Even without this you could probably assign multiple IPs to your server (and you'd already have that with IPv6) and bind each shairport to that address. (i.e. Docker is, yet again, superfluous)

From your outputs, it seems you are running just one instance of shairportsync in snapserver. Also port 5106 is not a standard one for AirPlay2 (7000 is). Could you please confirm, that you are able to run multiple shairport instances in AirPlay2 mode directly from snapserver and succesfully connect to them?

This project was written when AirPlay2 support was still very new so it is using Airplay 1.

I have an airplay (1) service running per-zone (so... 10 currently) on a range of ports from 5101 upwards. Default port doesn't matter much when the service is advertised by mDNS.

Added airplay2 as a feature-request #27.

[gregorij89]

There's discussion about mikebrady/shairport-sync#1444 which is a little later than the one you linked and it seems to hinge on the mDNS DeviceID.

Seems you need both general.airplay_device_id_offset and general.port settings.

Thank you for pointing me there. So the fix is quite easy. Adding general.airplay_device_id_offset settings to every config file fixed the issue. The port setting is not necessary to be added to conf file, as it is overridden by cmd argument from snapserver. Now I am able to have multiple instances of shairport-sync in AirPlay2 mode handled by snapserver.