Investigate Airplay 2 Support via shaiport-sync

[linknum23]

shairport-sync, the underlying airplay client that we use, is working on integrating some of the airplay2 features on their development branch

A couple of questions:

• Are we able to integrate our group support with theirs?
• Are streaming commands supported? -> yes!

[linknum23]

@Juggler00 What specific features are you looking for from airplay 2?

[Juggler00]

AirPlay 2 is more advanced that the original version. The original AirPlay 1 allowed you only to "cast" your audio/video to a receiving device: it was a server/receiver model. With AirPlay 2, once you select the AirPlay 2 receiver and it starts to play, other iOS devices can control the playback of the audio (play/pause, volume, next etc.). In the case of Apple Music, once you initiate playback on an AirPlay 2 receiver, you no longer actually need to be connected (i.e. your iPhone does not need to be actively casting the whole time). You can leave the house and the sound will continue to play and others will be able to control it.

In many ways, AirPlay 2 brings to Apple Music what all of the embedded Spotify players brings to Spotify.

There is also talk of higher bit-rates, but I was unable to find any specs on this.

[linknum23]

This is really helpful. I wonder if the development version shairport-sync has support for play/pause/next control yet? That itself would make adding this really worth it.

[Juggler00]

Looks like they don’t have the “remote control” features working yet. https://github.com/mikebrady/shairport-sync/blob/development/AIRPLAY2.md

[linknum23]

Hmm, maybe they are still reverse engineering that part of the protocol? I couldn't find a related issue to remote control though.

We will probably hold off on adding Airplay 2 support until remote control is integrated. Hopefully by that time the interface will be more stable as well.

[linknum23]

It looks like shairport is getting close to merging in airplay 2 support. We should test out a single instance on an amplipi soon:

• [x] build and install shairport (development branch) on amplipi10
• [x] change the airplay client to enable airplay 2 mode
• [x] test single zone functionality

To enable multiple simultaneous streams (later):

• [ ] Install docker on amplipi
• [ ] Make per stream docker compose files

[linknum23]

So i tested basic functionality last night and it seems to work for a single airplay 2 instance!

I tested this last night by removing the shairport-sync package installed by AmpliPi and following the build instructions on the development branch of shairport-sync to build and install shairport-sync and nqptp.

Then I enable and started the nqptp service so that it would be running when shairport-sync was started by AmpliPi. I was able run shairport-sync normally via AmpliPi after that and it showed up as an airplay 2 device. Playing a YouTube video seemed to work fine and shairport continued to work on AmpliPi as before.

[klay2000]

Yesterday I attempted to get multiple Airplay 2 instances working without using Docker. In order to do this I made 2 MACVLANs attached to the physical NIC in my PC, then put them in their own network namespaces. I then launched Shairport-Sync in both of them which made 2 airplay 2 devices appear, however connecting to them didn't work. After looking at the MDNS services they advertised I realized they were both pointing to the NIC and not the VLANs.

I believe this is because the Avahi daemon isn't running in the network namespace, but in order to run a separate Avahi daemon in the network namespace I'd need to isolate it from the rest of the system in a few other ways and this leads to a lot of other dependencies I'd need to spin up also isolated.

Today I'm going to attempt to get this working with Docker, the reason I didn't initially use Docker is the difficulty in getting audio out of multiple Docker containers with Alsa.

[rtertiaer]

I'm going to poke at this for a handful of hours, see if I can't get multiple AirPlay 2 instances to function at the same time & have Avahi work well. There are a couple of reasons:

• I'm currently packaging things in #472 to support automated image creation in #471. However, at present we build shairport-sync twice - once with airport 2 support, and once without, and run both versions simultaneously. Running only a single compiled binary simplifies packaging and feels more sane.
• the user experience of having to choose between airport 1 & 2, and perhaps consider limitations, feels incorrect; this should "just work", like Apple would want.

[rtertiaer]

Assuming that each shairport-sync Airplay2 instance needs to speak to its own nqptp, it would also be necessary to modify nqptp to bind to specific interfaces; right now, it listens on all.

[rtertiaer]

I have a theory. There's the possibility of doing fancy things with systemd networking & macvlan. Should all of nqptp, shairport-sync and the given avahi advertisement run in a control group with only access to a virtual ethernet device configured with macvlan, everything ought to autoconfigure correctly; it subsequently becomes trivial to create new airport 2 instances and virtual interfaces on the network, with distinct IP addresses to advertise. I'm going to play with this a bit further and examine if this is both possible and reasonable for a handful more hours yet before pivoting to something perhaps more immediately impactful (probably just packaging distinct airplay 1 & airplay 2 versions of shairport-sync.)

[rtertiaer]

Okay, on some level it's not worthwhile to rebuild the stack of software necessary here (avahi, dbus, isolated network interfaces bridged with the ethernet adaptor) when upstream offers a Docker container that's totally capable of this. I'm gonna forgo packaging shairport-sync entirely and instead use the upstream container; re-closing this.