Airplay Whole House Audio with Shairport-Sync and Forked-Daapd

Forked-daapd acts like itunes, so it can send audio (songs, playlists, internet radio web links…) to multiple airplay speakers on its own. I mention the use of shairport-sync only as a way to output audio from iOS apps to multiple airplay 1 speakers.

Right, that makes sense. I think I’m misunderstanding the roles of music servers, streamers and DACs.

I think I’ll give this a go this afternoon. Just as an aside, I have a media folder that is used with the Media Browser in Home Assistant. Could that folder be used instead of the “music” folder in the docker config?

If so, can I assume that it’s path would be /mnt/data/supervisor/share/media:/media?

Thanks for the write up.

Use these as the volumes

- /mnt/data/supervisor/share/daapd:/config
- /mnt/data/supervisor/media:/music

Thanks very much. Wasn’t very sure about the syntax.

Hey, just wanted to say thanks. I following your instructions and it appears to be working. Looking forward to seeing what I can do with it. Would never have been able to do that without your instructions. Thanks a bunch.

Quick question though. When I access the daapd server on port 3689, I keep getting a remote paring request from pyatv when ever I load the server page. Not really sure where this is coming from, but its the same IP address as the HA server and seems to be associated withe daapd server. If I load the apple TV integration, the dialogue shows “Aborted, Unexpected error”.

From the daapd server:

Screen Shot 2021-01-31 at 10.31.121236×450 19.3 KB

Apple TV integration:

Screen Shot 2021-01-31 at 10.30.51800×282 18.1 KB

Any ideas about what to do about this? Where do I obtain the pairing code?

*** Fixed after I restarted Home Assistant ***

Hey, does anyone else find the forked-daapd gets ‘stuck’ on the shair port stream / input? I’ve tried clearing the queue and removing it but when is select another track it just goes back to shair.

I find I have to go to portainer and restart the forkeddaapd and shairportsync containers to reset it.

Anyone else encountered this and/or has a way to clear the queue so it’ll play selected tracks? Not a biggie, but maybe I am missing something.

The only time mine ever got stuck was when I gave it bad playlist names. Other than that, it’s rock solid. But I use standard airplay devices, not shairport.

I started to have problems (requiring a restart of the forked-daapd and shairport-sync containers from time to time) after one of the Home Assistant OS updates.
I have switched to using a Debian 10 install of Home Assistant Supervised on my RPI4 and all is working well. This is a bit of work to switch from Home Assistant OS to Debian, so you will have to decide if it is worth it.

I now also switched to this method via Portainer, now that the addon no longer works. Thanks for the instructions! One question I still have: how to update forked-daapd to a newer version (in case it’s available)?

Here’s what I do to update, but I am not sure if it is the best way, using portainer:

1. In “Containers” remove the forked-daapd container
2. In “Images” remove the forked-daapd image
3. In “Stacks” select forked-daapd, go to the “Editor” tab and click the “Update the stack” button

This will pull the latest version of the image from the repository, in this case it is the version at linuxserver/daapd, you can check the latest version at:

OK, but its specifically related to the shairport input. Same happens when attempting to select another playlist or track directly within the forked-daapd web interface. It’s not a biggie, something I’m just wondering about.

I have HA running in a proxmox virtual machine on an intel nuc, pretty keen to stay with that.

Thanks for the tutorial.

I’m trying to build a setup around Airplay, Spotify, local music files and a mobile front-end.

The elements would be:
1 - Media server that can combine local files with Spotify (and possibly other streams / services)
2 - forked-dappd (now owntone-server to stream to AirPlay speakers
3 - A Mobile front end to control media and playing (an MPD client or apple’s remote iTunes app)

One options is to use mopidy + Mopidy-Spotify as an spority + local integrated music server AND slimmed down version of owntone-server - without the iTunes library or mpd server. In this setup we need to stream from mopidy to forked-dappd but I’m not sure the MPD clients or the remote iTunes app could mange changing streams / speakers.

Another option is to build around the full forked-dappd installation as the music server and integrated Spotify somehow (any ideas how to??) and use the remote iTunes app as a client using this script (un-tested)

Thoughts ???
Happy to work on something like this with you if you like.

Nadav

forked-daapd can be built wilth support for spotify, but not sure if the docker version I use has the option. You could install the native forked-daapd with the option:
--enable-spotify

I think forked-daapd (owntone) does all of that already, no?

Fantastic tutorial. Thank you! This solved an issue I’ve been wanting to take care of for years.

If I could make some notes & additions:

• Some of your shairport-sync.conf entries have no semicolons. (Not a big deal but could save someone a lot of head scratching.)
• More streamlined to:
  • copy shairport-sync.conf
  • put it in /mnt/data/supervisor/share/shairport/shairport-sync.conf
  • make appropriate edits.
  • change volumes section of docker-compose from:

      - /mnt/data/supervisor/share/music:/music
      - /mnt/data/supervisor/share/shairport:/config

to

      - /mnt/data/supervisor/share/music:/music
      - /mnt/data/supervisor/share/shairport/shairport-sync.conf:/etc/shairport-sync.conf
      - /mnt/data/supervisor/share/shairport/scripts:/scripts

• Unsure if it’s just something I didn’t get right but playing through the whole house airplay pipes my audio through two different sets of volume controls (phone & forked-daapd) resulting in cumbersome operation. You could use the forked-daapd api to change the volume but Mike Brady’s image is built on busybox which doesn’t have curl. So we resort to this cludgy but effective workaround.
  • Add a file /mnt/data/supervisor/share/shairport/scripts/vol.sh . Contents:

#! /bin/sh

printf "PUT /api/player/volume?volume=$1 HTTP/1.1\r\nUser-Agent: nc/0.0.1\r\nHost: 127.0.0.1\r\nAccept: */*\r\n\r\n" | nc 127.0.0.1 3689

• chmod 775 /mnt/data/supervisor/share/shairport/scripts/vol.sh
• modify in shairport-sync.conf again

        run_this_before_play_begins = "/scripts/vol.sh 100";
        run_this_after_play_ends = "/scripts/vol.sh 33";

I’m trying to figure out how to make an AirPlay 2-compatible setup using my existing 6 zone whole-house audio amp (which I can control via Home Assistant and a network bridge). I’ve read this thread but I’m still not totally clear on whether this could give me what appears to users to be a “native” AirPlay 2 style experience for people streaming music – that is, on an iPhone, in the Apple Music app (or whatever app they choose), a user can simply hit the “airplay” button on the iOS overlay and select which rooms (multiple) they want the music played in, and control the volume for each room independently. Each room being a Raspberry Pi with AirPlay, connected to a zone on my multi-zone amp.

I don’t think this is possible without having an airplay device connected to each zone, such as 6 old airport express devices.

Airplay 2 won’t happen I’m afraid, they haven’t cracked the protocol yet. But that being said you really don’t need it. You can stream in perfect sync to Airplay 1 speakers just fine from forked-daapd and shairport-sync and control the volumes of the rooms individually. This will be done in the home assistant UI or in the Remote App, not via the overlay (the audio is not streaming from your device, so regardless of what media server you choose including iTunes, it will never use that overlay).

And if they are airplay 2 capable devices you can still use them just fine from you iOS device and select multiple speakers with mixing (which is the only place this really should matter).

So I don’t think this will be an issue you will even notice. It should find all of your speakers unless they aren’t backwards compatible to airplay 1, but I haven’t personally encountered any devices like that. All my airplay 2 devices support airplay 1.