Individualized MQTT Remote Commands for AirPlay 2 Receivers

[stephenmetzger]

It seems that mqtt commands, when sent to the "[shairportreceiver]/remote" topic, affects all airplay devices that are currently streaming. For example, when streaming to an rpi-based shairport receiver "guestbedroom" and to an AirPlay 2 capable Airport Express, a "volumedown" payload to topic: guestbedroom/remote turns the each airplay stream down on each device, rather than just on guestbedroom.

Any thoughts on how mqtt commands could be used to control an individual AP2 receiver when streaming to a group? It would be nice to have an MQTT/IoT based button at each of my speakers that could be used to either mute or disconnect a single speakers, for those occasions while I am in one room and my wife is in another room and wants to "opt-out" of multiroom music.

[mikebrady]

Apologies for not seeing this for a while.

The issue is a bit more complex, and it revolves around how commands to Shairport Sync generally work.

What usually happens is that the commands like VolumeUp and VolumeDown are sent to the source of the audio, for example to the macOS Music app or to the iOS device playing the audio. It is then up to the source to deal with the command. So, for example, a VolumeUp command sent via MQTT is routed to the player and the player sends appropriate volume control changes to all the AirPlay devices connected to it.

This implies that the nature of the response to an MQTT command depends on the source. Evidently, the response to a VolumeUp command is to increase the volume level on all connected devices. So, unfortunately, we have no direct control over the nature of the source's response.

Some sources seem to be able to respond to an enhanced set of commands -- iTunes and macOS Music among them -- which includes the ability to adjust the volume of just one output device. If the source provides those extra commands, Shairport Sync can use them and they can be used via the Shairport Sync D-Bus interface, and presumably by MQTT.

Things are not good overall, though. First, recent versions of macOS Music don't seem to respond to these commands -- or if they do, something has changed. Second, it has not been possible to get any remote commands working with AirPlay 2.

You can see that the general organising principle at work here is to get as much as possible done under the direct control of the source; that is, to have as little local "autonomy" -- e.g. to mute the output or change the volume -- as possible. One could imagine adding a local mute, but the general issue is that the overall control of the playing experience would become fractured and chaotic. IMHO it would be much better to organise that this should be controlled by the player, but so far we just don't have the information...

[stephenmetzger]

No worries @mikebrady! Thanks for the detailed response. This makes sense. So, I've been thinking of how to implement workarounds. For anyone seeing this in the future, I plan to set up IoT buttons (probably a xiaomi aquaria button) at each shairport instance to send a systemctl restart shairport-sync command to the associated pi, which should restart shairport and effectively remove it from the AP2 group. No way I can think of to remotely, re-add it to the group, but the most important thing for me was to implement a way to quickly disconnect or mute an instance when access the the source is not immediately available.

[mikebrady]

Not a bad idea. There's a line in "Hercules" that might be appropriate 🙂.

[iChUdY]

Did something changed?
Shairport-sync developer AP2, Apple TV
For me, mqtt volumeup/volumedown only works if only one instance is connected. If two or more are connected, volumeup/volumedown stops responding.

I don't need to control each instance separately. It would be enough to control the volume for everyone at once.