Volume commands via MQTT not working (with SPS in Docker)

[rogersmj]

I'm sure this is me just missing something in my somewhat complex setup, but I haven't been able to figure it out and would really appreciate some help.

I have two instances of SPS running on Docker (on a Raspberry Pi). They're both configured identically except for their names and which Pulse Audio sinks they're pointed at. One instance is using the Pi's built-in audio, the other instance is using a USB sound card.

I use MQTT and @parauntenbach's hass-shairport-sync integration to expose and control my SPS players in Home Assistant. Mostly it works, except for volume. The entity in Home Assistant shows volume buttons:

and the volume commands are being transmitted through the MQTT broker:

But the volume of the playback doesn't actually change.

(strangely, there's no Mute button shown on the HA entity, or volume level, but not sure if that's a different issue.)

I can control volume of playback from my iPhone.

Before I switched to Docker and PulseAudio, I swore I remember being able to control the volume of SPS via Home Assistant/MQTT, and the docs in the config file suggest that volume commands are supported.

Here's my config file:

general = {
    name = "Main Floor";
    output_backend = "pa";
    //      volume_range_db = 60 ; // use this advanced setting to set the range, in dB, you want between the maximum volume and the minimum volume. Range is$
    //      volume_max_db = 0.0 ; // use this advanced setting, which must have a decimal point in it, to set the maximum volume, in dB, you wish to use.
};

pa = {
    sink = "FirstFloor"; // Set this to override the default pulseaudio sink that should be used. (Untested)
};

metadata =
{
        enabled = "yes"; // set this to yes to get Shairport Sync to solicit metadata from the source and to pass it on via a pipe
        include_cover_art = "yes"; // set to "yes" to get Shairport Sync to solicit cover art from the source and pass it via the pipe. You must also set$
        cover_art_cache_directory = "/tmp/shairport-sync/.cache/coverart"; // artwork will be  stored in this directory if the dbus or MPRIS interfaces a$
        pipe_name = "/tmp/shairport-sync-metadata";
        pipe_timeout = 5000; // wait for this number of milliseconds for a blocked pipe to unblock before giving up
//      socket_address = "226.0.0.1"; // if set to a host name or IP address, UDP packets containing metadata will be sent to this address. May be a mult$
//      socket_port = 5555; // if socket_address is set, the port to send UDP packets to
//      socket_msglength = 65000; // the maximum packet size for any UDP metadata. This will be clipped to be between 500 or 65000. The default is 500.
};

mqtt =
{
        enabled = "yes"; // set this to yes to enable the mqtt-metadata-service
        hostname = "192.168.2.2"; // Hostname of the MQTT Broker
        port = 1883; // Port on the MQTT Broker to connect to
        username = "shairport"; //set this to a string to your username in order to enable username authentication
        password = "REDACTED"; //set this to a string you your password in order to enable username & password authentication
//      capath = NULL; //set this to the folder with the CA-Certificates to be accepted for the server certificate. If not set, TLS is not used
//      cafile = NULL; //this may be used as an (exclusive) alternative to capath with a single file for all ca-certificates
//      certfile = NULL; //set this to a string to a user certificate to enable MQTT Client certificates. keyfile must also be set!
//      keyfile = NULL; //private key for MQTT Client authentication
        topic = "shairport/mainfloor"; //MQTT topic where this instance of shairport-sync should publish. If not set, the general.name value is used.
        publish_raw = "yes"; //whether to publish all available metadata under the codes given in the 'metadata' docs.
        publish_parsed = "yes"; //whether to publish a small (but useful) subset of metadata under human-understandable topics
//      empty_payload_substitute = "--"; // MQTT messages with empty payloads often are invisible or have special significance to MQTT brokers and reader$
//    To avoid empty payload problems, the string here is used instead of any empty payload. Set it to the empty string -- "" -- to leave the payload emp$
//      Currently published topics:artist,album,title,genre,format,songalbum,volume,client_ip,
//      Additionally, messages at the topics play_start,play_end,play_flush,play_resume are published
        publish_cover = "yes"; //whether to publish the cover over mqtt in binary form. This may lead to a bit of load on the broker
        enable_remote = "yes"; //whether to remote control via MQTT. RC is available under `topic`/remote.
//      Available commands are "command", "beginff", "beginrew", "mutetoggle", "nextitem", "previtem", "pause", "playpause", "play", "stop", "playresume"$
};

[mikebrady]

Thanks for the post. Can you be sure that the commands are reaching the Shairport Sync instances in the Docker containers?

[mill1000]

I was able to recreate a similar issue using AirAudio on my Android device. I can confirm that in my case, the commands are reaching Shairport Sync, but it appears either the DACP command isn't going through, or the response isn't received.

In my case, it seems to happen after the phone is locked (screen shuts off).

Working volume up command

         0.868114479 "mqtt.c:55" [MQTT]: received Message on topic stereoberry/shairport/remote: volumeup

         0.000075625 "mqtt.c:68" [MQTT]: DACP Command: volumeup

         0.000029375 "dacp.c:370" send_simple_dacp_command: sending command "volumeup".
         0.034130260 "rtsp.c:3556" Connection 4: request to set AirPlay Volume to: 0.000000.
         0.002980156 "audio_alsa.c:2050" mute(0) set_mute_state
         0.000404323 "player.c:3356" player_volume_without_notification: volume mode is 1, airplay volume is 0.00, software_attenuation dB: 0.00, hardware_attenuation dB: 0.00, muting is disabled.
         0.000041563 "mqtt.c:108" [MQTT]: publishing under stereoberry/shairport/volume

Non-working command

         0.480991146 "mqtt.c:55" [MQTT]: received Message on topic stereoberry/shairport/remote: volumeup

         0.001418698 "mqtt.c:68" [MQTT]: DACP Command: volumeup

         0.001252656 "dacp.c:370" send_simple_dacp_command: sending command "volumeup".
         0.516589479 "rtp.c:516" AP1 control thread: set_ntp_anchor_info: rtptime: 1778679, networktime: a8bda1beb, frame adjustment: -11.800.
         0.895431666 "rtp.c:774" clock synchronisation request: return time is    6.316 milliseconds.
         0.101972240 "rtp.c:516" AP1 control thread: set_ntp_anchor_info: rtptime: 1822679, networktime: ac765a3ab, frame adjustment: -55.900.
         0.997490572 "rtp.c:516" AP1 control thread: set_ntp_anchor_info: rtptime: 1866679, networktime: b02e1e92b, frame adjustment: -11.800.
         1.000862031 "rtp.c:516" AP1 control thread: set_ntp_anchor_info: rtptime: 1910679, networktime: b3e7cb32b, frame adjustment: -100.000.
         0.724304583 "mqtt.c:55" [MQTT]: received Message on topic stereoberry/shairport/remote: volumeup

         0.001073958 "mqtt.c:68" [MQTT]: DACP Command: volumeup

I realize it could very well be a buggy implementation on AirAudio's side as well.

[mikebrady]

Thanks for this. In both the working and non-working versions above, it seems that Shairport Sync is sending the volumeup request to the player (at dacp.c:370), but only in the working version is a command coming back from the player (at rtsp.c:3556), so it does look as if the player (AirAudio?) is misbehaving...

[mill1000]

Does shairport sync create a new connection for each DACP command or reuse an existing one?

I wonder if AirMusic (formally AirAudio) terminates its DACP listener when the screen goes blank.

I also run an Owntone server so I can try to reproduce it there as well.

[mikebrady]

A new connection each time, IIRC.

[mill1000]

I'll see if I can do some packet captures as well .