shairport-sync failing to post "pw=true in avahi for Airplay 1

[janui]

What happened?

When a password is present in the configuration file or specified when starting shairport-sync, the text "pw=true" is not present in the '_raop._tcp' avahi line for AirPlay 1.
In this case I would expect "pw=true" to be present.
See attachment for shairport-sync logging (using -X --password=abcd), and the results of avahi-browse.
janui

Shairport-sync failing to post 'pw=true' in avahi.txt

Relevant log output

All information is in the attachment

System Information.

All information is in the attachment

Configuration Information.

All information is in the attachment

PulseAudio or PipeWire installed?

• Check if your system uses a Sound Server.

How did you install Shairport Sync?

Homebrew for Mac

Check previous issues

• Confirm

[mikebrady]

Thanks for the post. We'll check it out!

[mikebrady]

This seems to be working alright here. Note that the pw=... entry is not present at all if Shairport Sync is built for AirPlay 2. You can use the app Discovery from Tildesoft on macOS and iOS to see what is being advertised on Bonjour.

[janui]

Hi @mikebrady, Thanks for the fast response.
I am using Shairport Sync from the Debian repo:

root@runeaudio(rw):/# apt list shairport-sync
shairport-sync/stable 4.3.7-1 arm64
shairport-sync/stable 4.3.7-1 armhf

This is the version string:

4.3.7-AirPlay2-smi10-alac-OpenSSL-Avahi-ALSA-jack-stdout-pipe-soxr-metadata-mqtt-dbus-sysconfdir:/etc

It looks like it is built with AirPlay 2, so it would seem correct that the pw=... is not being broadcast.

However I have a bit of a chicken and egg problem with this. I am currently fine tuning a solution with Owntone as AirPlay source. Owntone will always connect with AirPlay 1 and it will correctly connect with password security, but only when pw=true is broadcast. Owntone looks only at _raop._tcp to determine whether a password is required. Would it be possible to include the pw=... in the _raop._tcp avahi broadcast when a password is set? And if so, has shairport-sync built with AirPlay 2 the capacity to process the AirPlay 1 password handshake? Note that I am asking these questions without knowing anything about the complexities of AirPlay. But as I understand it (and please correct me if I don’t have it right), an AirPlay 1 connect request sent to a password-protected Shairport Sync (built with Airplay 2) would always fail since the source cannot determine the need of a password. So, is the password security actually depreciated for the Airplay 2?

janui

P.S. I have looked at some other AirPlay 1/2 posts and know that I could start an Shairport Sync version without Airplay 2 when a password is set. But I would rather have an AirPlay-2-capable receiver active which could gracefully degrade to full function Airplay 1 when required.

[mikebrady]

The reason for omitting the pw=... stuff was to copy what was already out there, as we don't have any specifications for AirPlay.

An update has just been pushed into the development branch that adds pw=true when there is a password.

Please tell us if it works for you. If it breaks compatibility or functionality now or in the future, then we'll have to remove it.

The AirPlay 2 password stuff has not been implemented (or investigated) for Shairport Sync.

[janui]

Hello mikebrady,
Sorry for the delay in answering. Depreciating “with-apple-alac” threw me for about a week. I could not get any sound, so, I assumed we had a build problem. Now that is solved, I can confirm that publishing “pw=true” in the “ _raop._tcp” avahi broadcast when a password is set works correctly for Airplay 1 connections originating in owntone.
janui