Since the maintainers of DietPi do fantastic things when it comes to optimizng apps, I don’t want to mess with by tickering with nqptp installations and the like.
I’ll update our Shairport Sync packages soon, but based on latest stable release. If you tell me the SBC/architecture/distro version you are using, I can compile one testing package based on development version, to test whether Airplay 2 works well with it .
cat /proc/cpuinfo
processor : 0/1/2/3
BogoMIPS : 38.40
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : BCM2835
Revision : 902120
Serial : 00000000ff6e1836
Model : Raspberry Pi Zero 2 W Rev 1.0
What is the status of this request? Does the shairport-sync package of DietPi support Airplay2?
Edit: Just saw that yesterday v4.1 was released with support for Airplay2, so I guess it is not included yet in DietPi but I hope soon Releases · mikebrady/shairport-sync · GitHub
Requires an additional daemon running as root user, listening on two additional ports.
Requires more CPU power, not recommended for RPi 1 and Zero (1), probably acceptable
What I can think of is that we build ARMv6 packages without AirPlay 2 and all others with AirPlay 2 and the NQPTP daemon just shipped embedded into the same package.
What I’m not sure about is whether, if users do not want/need AirPlay 2, NQPTP can be just stopped, or whether Shairport Sync strictly requires it when being compiled against it.
Not sure about the AirPlay ecosystem, if/how fast AirPlay 2 is supported by existing devices, but to me it seems that we either need to stay with AirPlay 1, to not break things for users, or ship two packages for all architectures where users can choose from.
Good to know. I’m anyway going to update and move Shairport Sync packaging to GitHub actions. When on it, I’ll try to add optional AirPlay 2 builds. Would be a dietpi.txt setting and dialog in dietpi-software then to choose between AirPlay 1 and 2.
@kwagga@chnbz would be great if you find time to test the packages with AirPlay 2 support. They install fine and services run well, but I have no Apple infrastructure to test actual connectivity and playback.
@kwagga
Many thanks, highly appreciated. Was there anything required client side to use AirPlay 2 or do clients choose the protocol automatically, based on what the node supports?
@chnbz
Many thank! I’ll likely add a dietpi.txt setting + choice prompt in dietpi-software for the DietPi v8.11 Beta Saturday night. Depending on when you find time, you may test this one and give feedback on the prompt and given information .
@MichaIng Did some more testing, so far works perfectly.
As for how the protocol negotiates with clients, I can show you, but in typical Apple-style, there are almost no settings or options to choose - everything is automatic, which is good and bad I guess. The highest quality protocol is automatically chosen.
Multi-Device/Room streaming works also. Quality seems great, while there is few milliseconds lag, this can be corrected in the config file, and is not caused by anything DietPi.
Thanks for testing guys . Great that it works so well and switching back and forth between AirPlay 1 and 2 can be done seamlessly.
At the moment the AirPlay 1 build is installed by default. Do you think it makes sense to install the AirPlay 2 build by default? “Slightly” more CPU usage, a little more memory and ~150 MiB additional disk space usage are no big issue. And we if the system really is overloaded, it can be downgraded easily.