The screenshots of the RPI-monitor were a little puny, these should be better

I have a PiZeroWH which I've just setup for Airplay 2. It has Pirate Audio's DAC Shim installed. I disable onboard audio when I have a DAC in the mix.

It works pretty well until you do any of the following:

• Pause
• De-select it from the Airplay menu on your streaming device and then reselecting

On doing either of these things, audio ceases to go to Shairport-Sync and this is reflected in the CPU usage; when streaming its around 30% whilst Shairport-Sync idles at about 7% when not receiving the audio.

You can re-select the device but pressing play yields no audio. Sometimes the source won't allow the music to be played at all.

The fix appears to be restarting the Service, but this only works about 75% of the time. I'm going to do the tweaks listed above and see if that makes a difference.

I should note: I had normal Shairport-Sync on this unit and removed it to put the Airplay2 version on. In order to be absolutely sure it wasnt a configuration issue from the lingering installation, and I rebuilt the PiZero from scratch and install the Airplay2 version fresh; and the issue persists.

I am not the developer of shairport-sync, just the threadstarter, but here are my two cents on the issues that Chris Walker have reported.
1. Shairport-sync does not play music on IOS when you disconnect and reconnect.
I can partly reproduce this problem, but if I disconnect and reconnect repeatedly (4-5 times), then suddenly it starts playing again. If I do not connect/disconnect repeatedly, I observe the same as Chris....namely that no sound comes from the pi zero
2. Shairport-sync will not play from the Apple Music, unless you select the pi as System Audio on macOS.
Again I can reproduce this problem.....but if I first select another source (in my case an ATV4K) and then select the pi as a second source it will start playing. After this I can deselect the atv4k and the music plays only on the pi from within the Apple Music interface. At this point I can select and deselect the pi at will with no issues.

I agree that these bugs could arise from either i)piZeroW, ii)Shairport-sync or iii)IOS/macOS, but it seems both bugs can be "fixed" without restarting the service.

Thanks for all the interesting observations.

There's a bit more to add to it. At the moment, there are two types of AirPlay 2 streams — Realtime and Buffered. The Realtime stream is ALAC-encoded and the Buffered stream is AAC-encoded. The development version of Shairport Sync supports both.

Different apps and modes select a stream type automatically. Apple Music on iOS and on macOS uses Buffered Audio, thus AAC. System Audio on macOS, Tunein Radio and some others use Realtime Audio, thus ALAC.

Decoding ALAC seems to take considerably less CPU effort than decoding AAC. In fact, Realtime Audio streams will play on an original Pi where Buffered Audio streams will not work at all. It's also worth remembering that the 40% CPU load when working normally on a Pi Zero is an average figure.

So, my feeling is that the Pi Zero is able to keep up with a Realtime Audio stream rather easily but, for some reason, is only able to keep up with a Buffered Audio stream under favourable conditions. There may be some peculiarity of the Buffered Audio processing chain that makes it particularly susceptible to delays and glitches, but I haven't been able to find it.

Two things that might be worth experimenting with if you wish are:

1. Set the interpolation mode to basic to avoid the possibility that soxr-based interpolation, chosen automatically, is bogging the system down.
2. Set the compilation flags to do the highest level of optimisation and see if it makes a difference. Something like:

CFLAGS="-O3 -g" CXXFLAGS="-O3 -g" ./configure ...

Not sure it makes much difference, TBH, but worth trying.

Definitely good fun alright 🙂.

The new Zero 2 W works without ANY of the above mentioned problems. I think that corroborates Mike Bradys suggestion that the original Pi Zero W is struggling with some peculiarities from the buffered audio stream. So if you want AP2 in the small form factor, I think it is a no-brainer to suggest the new Pi Zero 2 W :-)

I wanted to share my experience with AP2 and the pi zero 2 w as well as extend my appreciation to Mike and everyone who has contributed to getting AP2 up and running!

I was able to get AP2 running perfectly on the pi zero 2 using a very inexpensive PCM5102A DAC ($10-$12 on ebay or amazon). I'm using the latest raspberry pi OS.

I have several hifiberry DACs (DAC+ Standard & Zero) and the sound with this inexpensive DAC is identical (Hifiberry uses the PCM5122 chip - the only difference is the the 5122 has hardware volume control which I don't need).

gpio configuration for DAC:

SCK        	 > Not wired 	(Internally generated) 
BCK       	 > PIN 12    	(GPIO18)
DIN        	 > PIN 40    	(GPIO21)
LRCK      	 > PIN 35    	(GPIO19)
GND       	 > PIN 6    	(GND) Ground
VIN       	 > PIN 2     	(5V)

Pi configuration:

Add the following to /boot/config.txt:

dtoverlay=hifiberry-dac

Here is the contents of /etc/shairport-sync.conf:

// Sample Configuration File for Shairport Sync on a Raspberry Pi using the built-in audio DAC
general =
{
  volume_range_db = 60;
};

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

Reboot and you are good to go!

Interestingly, the aplay -L shows this DAC as a hifiberry DAC:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 [HifiBerry DAC HiFi pcm5102a-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

top shows about 22% cpu.

This is one of the least expensive good quality AP2 setups that I've built. I've streamed for several hours on this build and have had zero issues and the Pi stays relatively cool. The toughest part of this project was soldering the gpio header pins. I'm hoping they will have the pre-soldered headers soon??

As this thread is about the Raspberry Pi Zero (not the Zero 2) and Zero 2's are not easy to get on the market currently, I'd like to confirm the observations above in a less technical language: The Pi Zero indeed works well enough with AP2, with some limitations (which, if I understand Mike's summary explanation correctly, are not bugs, but result from the Pi Zero not having enough processing power for some tasks needed sometimes for certain AP2 streams, and there's no way round it):

1. Works well from iOS; not sure if on iOS there is really a difference between "system audio" and selecting Airplay from within, say, the Music app or Spotify, but since I don't know what they do and Spotify certainly does something else than the control center when selecting AP from within the Spotify app, I always select Airplay from the control center, and like that it has been working perfectly for me. Indeed some events might make it unstable, such as reconnecting, but it plays in sync with no distortions and overall it's very good. From iOS, you also can select multiple Airplay targets, one of them being the Pi Zero (from a non-technical user perspective, this is all what AP2 is about), and I have no issues serving a heterogenous network consisting of two shairplay-sync clients (Pi 4 and Pi Zero), a Sonos AP2 mono speaker, and a HomePod Mini at the same time from an iPhone (I don't think the iOS version matters). The Zero can do some minor tasks alongside shairplay-sync, but your installation will have to be "almost dedicated". (Note that Hifiberry OS includes the AP2 development branch for shairport-sync, but will distort audio between tracks because of other things; you must do your own clean and bare bones install of Raspberry Pi OS Lite, as I believe Mike explains in the wonderful documentation to his superb piece of open source software).

2. On MacOS and with standard tools, the Zero indeed will only play via system audio, never from Apple Music, and again certain events might make it unstable, but usually you can solve these by reconnecting (note that it is not really system audio because macOS will still output system chimes to the local system), and it's fine. However, and that is the crucial thing, macOS system audio only can go to a single AP target, you can't do multi-target (it's been like that for ages, even for AP1 and iTunes -- multi-AP target from iTunes has been possible since a long, long time, even in AP1 times, if I recall correctly). You could only do that from within the Apple Music app, but that's where the Zero does not work .

3. For macOS, there is a solution for multi-target that works: Airfoil lets you push macOS system or even application audio to several AP targets at once, and that includes the Zero. It's not as convenient in terms of volume control and play/pause (I hate lag in control), but it generally works good enough. (Not an ad for Airfoil, I knew it from ages ago and did not bother to research if there are alternatives). It would be interesting to find out if Airfoil sends an AP1 or AP2 stream (and if that, what kind) to the Pi Zero, but tbh I don't care enough to investigate.

4. Summed up, the Zero works good enough, but I'll be getting myself a Zero 2 once prices are back to normal.