RHEL 8 machine as AirPlay receiver

Step 1. Set up the GetPageSpeed repository

As always, we package the software you love to use in CentOS/RHEL.
The AirPlay receiver software, shairport-sync, is available from the GetPageSpeed repository.

sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm

Step 2. Install shairport-sync

sudo dnf install shairport-sync shairport-sync-firewalld

Step 3. Enable and start service

sudo systemctl enable --now shairport-sync

Step 4. Enable FirewallD service

Make sure that your connection profile is bound to the home Firewalld zone by setting your home network properly.

Finally, allow all the necessary AirPlay service in the home zone:

sudo firewall-cmd --zone=home --add-service=airplay-server --permanent
sudo firewall-cmd --zone=home --add-service=mdns --permanent # not really needed as this is the default for home zone
sudo firewall-cmd --reload

To verify firewall configuration I usually ran iptables -L -n, however, neither that nor iptables-save would show complete firewall state, e.g. if you run iptables-save you would see the following at the end of output:

> # Table `firewalld' is incompatible, use 'nft' tool.

Conclusion? Use one tool for the task: firewall-cmd --info-zone=home would yield:

home (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources: 
  services: airplay-server cockpit dhcpv6-client mdns samba-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Troubleshooting

The following command will watch for log messages from shairport-sync:

journalctl -f -u shairport-sync

Make sure to specify hardware device for the alsa output backend

If things don’t work as expected, try running shairport-sync -h and take note of the output (different based on the machine you use):

hardware output devices:
 "hw:CinemaTM"
 "hw:PCH"

Edit /etc/shairport-sync.conf with the device you want to use:

alsa =
{
  output_device = "hw:PCH"; 
};

This will use the first subdevice, with 0 index. TO use a different subdevice, run aplay -l and take note of device <integer> in the output:

card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 0/1
Subdevice #0: subdevice #0

then adjust as needed, e.g.:

alsa =
{
  output_device = "hw:PCH.3"; 
};

Use on a desktop machine

I’ve had an issue that the above didn’t work when I switched to audio via DisplayPort.

It seems that in this scenario, PulseAudio completely takes over the ALSA device, so audio fails to be sent to it.

On a PulseAudio-enabled system like CentOS/RHEL 8, it’s best to stick to pa output backend, unless you’re running headless.

Moreover, on a desktop machine, it simply makes sense to set up shairport-sync to be run under the primary desktop user, to avoid different users’ PulseAudio servers fighting for the same ALSA device.

Using pa backend plus user-specific shairport-sync daemon worked out better. In /etc/shairport-sync.conf:

output_backend = “pa”;

Create /etc/systemd/user/shairport-sync.service with contents:

[Unit]
Description=Shairport Sync - AirPlay Audio Receiver

[Service]
ExecStart=/usr/bin/shairport-sync

[Install]
WantedBy=multi-user.target

When logged in as your main desktop user, run:

systemctl --user enable --now shairport-sync

Make sure that even you don’t log in to that user, the service runs:

sudo loginctl enable-linger $USER

The journalctl may expose this error on reboot:

pulseaudio[1876]: E: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type=”method_call”

According to /etc/dbus-1/system.d/bluetooth.conf, lp group (printing subsystem) has access to
Whether it’s a big security risk that this desktop user is fine to be able print stuff, there is nothing else you can do aside from the workaround, add the user to lp group:

sudo usermod -a -G lp $USER

Make sure to replace $USER with an actual username, in case the user you set up shairport-sync to run with is different from your sudo-enabled user.

After this, reboot to apply group assignment.

Running with PulseAudio on a headless server (untested completely)

Ideally, we should combine the “user-specific daemon + pa backend” approach with the existing shairport-sync user.
First, make sure that the shairport-sync user can log in interactively by changing its shell via chsh.

You might have DBus related issues when running user daemons with SystemD without X11.
See below fixes:

sudo -iu shairport-sync
[shairport-sync@life ~]$ mkdir -p ~/.config/environment.d
[shairport-sync@life ~]$ echo "export XDG_RUNTIME_DIR=/run/user/$UID" > ~/.config/environment.d/fix-user-daemons.conf  
[shairport-sync@life ~]$ export XDG_RUNTIME_DIR="/run/user/$UID"
[shairport-sync@life ~]$ systemctl --user enable shairport-sync
sudo loginctl enable-linger shairport-sync
reboot

As you see, PulseAudio makes things quite complex. Being a “wrapper” for ALSA system and typically run as per-user service, it requires quite some workarounds, especially when dealing with some SystemD issues.

So on a headless server it might be worthy disabling it altogether with:

sudo systemctl --user --global disable pulseaudio

And following that remove any trace of it:

I found a solution. I expected ALSA configuration files to be somewhere in the /etc directory but they are in /usr/share/alsa and there is alsa.conf.d directory where it is possible to add additional devices. I removed pulseaudio files and arecord -L stopped to list pulse device. But it didn’t solve a problem as there was one more configuration file in my home directory .asoundrc which set default pcm to pulse. After removing it everything works fine.