[Problem]: HomeKit AirPlay 2 incompatibilities

[cbrunnkvist]

What happened?

I'm documenting these issues here mostly in order to save other users from having to go through the same troubleshooting, but hopefully there might be some fix in the future too:

There are two, probably interrelated, parts to the current HomeKit incompatibilities:

1. In Apple Home > Settings there are three access levels for "Speakers & TV":
   • Everyone
   • Anyone on The Same Network
   • Only People Sharing This Home

As concluded originally by @ghost in https://github.com/mikebrady/shairport-sync/issues/1442#issuecomment-1060709537, in order to be able to add Shairport Sync speakers to a Home at all, you are required to switch the "Speakers & TV" access mode of your Home to mode "...Same Network" and disable "Require Password", which in some cases is an undesirable workaround.

Failing to change access mode results in a confusing error along the lines of "make sure your device is connected to the WiFi network".

2. Once added, the status of the Speaker in my Home never seems to accurately reflect its current playback status: in the Home app from the device playing, it show blank status but when you tap on it you get your local media controls - on other devices in the Home, the speaker status is "No Response"

Example: playing from iPad, check Home status on iPhone:

Relevant log output

No response

System Information.

The Docker container :latest running on x86, dockerd in LXC, "host" network mode, Alsa device passthrough.

Configuration Information.

N.b. I use the default all-commented-out config file.

>> Display Config Start.

From "uname -a":
 Linux dockge 6.8.4-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.4-2 (2024-04-10T17:36Z) x86_64 Linux

From /etc/os-release:
 Alpine Linux v3.17

Shairport Sync Version String:
 4.3.3-dirty-AirPlay2-smi10-alac-OpenSSL-Avahi-ALSA-pa-dummy-stdout-pipe-soxr-convolution-metadata-mqtt-dbus-mpris-sysconfdir:/etc

Command Line:
 shairport-sync --displayConfig

Configuration File:
 /etc/shairport-sync.conf

Configuration File Settings:
 pw : 
 {
 };

>> Display Config End.
>> Goodbye!

### PulseAudio or PipeWire installed?

- [X] Check if your system uses a Sound Server.

### How did you install Shairport Sync?

Docker

### Check previous issues

- [X] Confirm

[mikebrady]

Thanks for the information!

Unfortunately we don't know enough about the AirPlay 2 protocols yet to fix the playback status issue.

[cbrunnkvist]

I see. So, as it stands, besides from "cool - adding works!" ;-) I don't see any advantages to adding my speaker to the Home setup at the moment since it doesn't bring any of the advantages ... Still works fine without lag for regular AirPlay, and at least I can protect it using nftables/iftables/ebtables, if push comes to shove.

[mikebrady]

Well, oddly, if you have a HomePod mini and you add the Shairport Sync device to a room, you can get Siri to play to it and raise and lower its volume and stuff.

TBH it is a bit frustrating that it sorta works. 🤷‍♂️

[cbrunnkvist]

I have an Apple TV 4th gen set up as home hub. It can stream audio (but not games/realtime?) to Shairplay, but again having the speaker part of the Home vs. just having it sit on the network makes no practical difference for that use case.

I read up on https://emanuelecozzi.net/docs/airplay2/authentication/, and I understand it's still an unsolved (MFi-) mystery.

As I understand it, we've got password protection working in AirPlay 1 mode though. Are there any particular downsides for running it that way, for casual music streaming? I mean, if you really need/want no free-for-all network access.

[mikebrady]

Yeah, password protection has not been implemented for AirPlay 2.

If I indeed your comment correctly, TBH I can’t see a serious downside to this, apart from the potential annoyance of someone else playing something of their own. Given that AirPlay only works within a subnet, it’s hard to see it as a big problem. YMMV of course.