Shairport-sync

Community Builds, Projects & Packages
1

Hi, there’re issues around Airplay versioning that a lot of folks seem to not be aware of that I’ll touch on here just to get it out of the way.

Airplay 1 can transmit/receive uncompressed audio, Airplay 2 transcodes to 256 kbps.

It appears as though the OpenWRT Shairport-sync module is configured to Airplay 2, is there anyway that’s reasonably straightforward to either source from another repo that anyone’s aware of to take advantage of an Airplay 1 Shaiport-sync without having to compile from source?

TIA

2

There are different variants of shairport-sync available in openwrt and the -openssl variant looks as though it is build with airplay2 support, but the default, -mini and -mbedtls variants are not.

1 Like
3

Thanks for looking into it Kelmo, the openssl variant’s the only one I’ve not tried (currently using mbetls)

Two indicators suggest mbetls’s airplay2, one is subjective (it sounds like a 256kb file) but secondly there’s an indicator on an iphone for example that is a tick in a closed circle for airplay2 while it’s an open tick for airplay1. This’s how ios indicates what kind of transmission you have.

I’m actually keen to nut out how I might learn to compile things myself but am just starting on a hgher degree and can’t see a time when I’ll get a chance to in the near future

version for mbetls displays as 4.3.2-AirPlay2-smi10-libdaemon-mbedTLS-Avahi-ALSA-pipe-soxr-metadata-mqtt-sysconfdir:/etc

4

Looks as though I have an additional complication – I have 2 instances of shairport-sync running

If i input shairport-sync --statistics i get a could not establish a service on port 7000 message, that another instance may be running. could just be the port’s in use by something else i guess

if I disable shairport-sync service /usr/bin/shairport-sync is active (though this is also airport 2)

edit: the second instance is a daemon.

looks like the mbedtls version is supposed to be airplay one but it’s definitely reporting as airplay2 on my system

5

I do not think the –statistics options is behaving how you may expect it too, and is attempting to daemonise, but you already have a process running.

Running a very recent build of openwrt snapshot and -mbedtls variant:

# shairport-sync -X 2>&1 | grep -A1 Version
Shairport Sync Version String:
 4.3.6-libdaemon-mbedTLS-Avahi-ALSA-pipe-soxr-metadata-mqtt-sysconfdir:/etc
# shairport-sync -v 2>&1 | grep Startup
         0.002842462 "shairport.c:2285" Startup in classic Airplay (aka "AirPlay 1") mode.

My understanding is that I wouldn’t be able to send anything to an Airplay2 endpoint using the airplay bridge for Lyrion, and I can. So pretty confident in that only the -openssl variant is configured to use the newer protocol.

6

Thanks again, this could be part of my problem as my firmware’s opkg repo’s privately hosted so it’s built from 24.10.*

I can see in Ted’s makefile that both the mini and mbedtls variants are supposed to be airplay classic but this build (definitely mbedtls) is reporting as .3.2-AirPlay2-smi10-libdaemon-mbedTLS-Avahi-ALSA-pipe-soxr-metadata-mqtt-sysconfdir and is indicated in iOS as airplay 2 as well

I’m beginning to think I need to compile it myself or badger the host to look into things from their end

Thanks again for your time, you’ve really helped me to nut this out a bit

7

In case anyone has an interest I’m running shairport-sync classic in a podman container which’s works fine other than using a ton of ram (most of that used by podman/docker-compose)

Hoping the repo build is rectified to follow the makefile and I can claw that ram back at some point