[Problem]: Issue with volume control when multiple Shairport-Sync instances are grouped

[killerlife]

What happened?

Description

I am running multiple instances of Shairport Sync on a Linux machine using Docker. Volume control behaves differently depending on whether a single instance or multiple instances are connected from the phone.

Observed behavior

1. When the phone app connects to only one Shairport-Sync instance, changing the volume from the Shairport-Sync side correctly updates the volume displayed in the phone app.
2. When the phone app connects to multiple Shairport-Sync instances in a group, changing the volume from one Shairport-Sync instance causes the volume of all grouped players in the phone app to change.
3. The resulting volume values shown in the phone app are not consistent with the value set from Shairport-Sync.

How the volume is being changed

I am using the command from sample.dbus.commands:

dbus-send --print-reply --system
--dest=org.gnome.ShairportSync
/org/gnome/ShairportSync
org.freedesktop.DBus.Properties.Set
string:org.gnome.ShairportSync
string:Volume
variant:double:-10.0

Question

1. How can I further diagnose or debug this behavior?
2. Is this expected behavior when multiple AirPlay receivers are grouped?
3. Is there a recommended way to control volume via D-Bus in this multi-instance setup?

Any suggestions on how to locate the root cause or resolve this issue would be greatly appreciated.

Relevant log output

System Information.

Raspberry Pi 4, 2 x USB Sound Card

Configuration Information.

>> Display Config Start.

From "uname -a":
 Linux MediaCenter 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

From /etc/os-release:
 Debian GNU/Linux 11 (bullseye)

From /sys/firmware/devicetree/base/model:
 Raspberry Pi 4 Model B Rev 1.5

Shairport Sync Version String:
 4.3.7-AirPlay2-smi7-alac-OpenSSL-Avahi-ALSA-pa-pipe-soxr-metadata-dbus-sysconfdir:/etc

Command Line:
 ./shairport-sync --displayConfig
No configuration file.

>> Display Config End.
>> Goodbye!

PulseAudio or PipeWire installed?

• Check if your system uses a Sound Server.

How did you install Shairport Sync?

Built from source

Check previous issues

• Confirm

[mikebrady]

Thanks for the post. Could you let us know what devices, OSs and apps you are using, please? And their version numbers would be very useful. Then we can try to replicate the issue.

[killerlife]

Thanks for reply.
When I enter the container using docker -it and run the following command:

dbus-send --system --print-reply --type=method_call --dest=org.gnome.ShairportSync '/org/gnome/ShairportSync' org.gnome.ShairportSync.RemoteControl.SetAirplayVolume double:-10.0

the dbus-send command hangs and does not return.

I will need some time to perform cross-testing to identify the root cause and collect more detailed information. Once the testing is completed, I will provide an update with additional details.

[mikebrady]

Thanks. Just a couple of things:

• Running multiple AirPlay 2 instances in Docker on a single machine is really quite complicated -- it would be worth looking through issues (including closed issues) and discussions to see how some users have done this.
• It also seems that Shairport Sync's remote control does not work on recent versions of Apple Music and other AirPlay sources.

[killerlife]

I performed some cross-testing and observed the following behavior.

When running Shairport Sync 5.0.0 inside Docker, the dbus-send command executes successfully. At the same time, I can see the following logs in the console:

0.579582565 "dbus-service.c:451" Set airplay volume to -30.000000.
0.000056703 "dacp.c:385" send_simple_dacp_command: sending command "setproperty?dmcp.device-volume=-30.000000".
0.419921523 "rtsp.c:5090" Connection 3: (PTP stream) received an RTSP Packet of type "POST":
0.000061166 "rtsp.c:5093"   Type: "CSeq", content: "371"
0.000017666 "rtsp.c:5093"   Type: "User-Agent", content: "AirPlay/925.5.1"
0.000015667 "rtsp.c:5093"   No Content Plist. Content length: 0.
0.000085332 "rtsp.c:5154" Connection 3: (PTP stream) RTSP response:
0.000019925 "rtsp.c:5156"   Response Code: 200.

However, the volume slider in the iPhone app does not update after I change the volume using dbus-send.

If I disconnect the current AirPlay session and reconnect, the volume slider in the iPhone app then updates to the value I set using dbus-send.

This means that every time I change the volume via dbus-send, I need to disconnect and reconnect AirPlay for the volume slider on the phone to reflect the new value.

I also tested the same setup without Docker, running Shairport Sync directly on the host system. The behavior is exactly the same: the volume change works internally, but the iPhone app's volume slider only updates after reconnecting the AirPlay session.

My test environment is:
iPhone 11
iOS 26.2.1
Spotify 9.1.28
Apple Music (same behavior).

[mikebrady]

Many thanks for your careful testing and results.

Unfortunately, it confirms the fact that recent versions of AirPlay 2 have dropped support for the remote control facilities Shairport Sync and other third party applications have relied on until recently. To our knowledge, the new system or systems have not been reverse engineered, but see here for some ongoing efforts.

When you update the volume with dbus-send, a remote control message (send_simple_dacp_command) is sent to the source but is ignored. However, the new volume is stored in Shairport Sync and offered as the initial volume for new connections; hence the behaviour you have observed.

[killerlife]

Thank you for your detailed explanation! The explanation about the initial volume behavior, in particular, gave me a much deeper understanding of the issue. Thanks again!