AirConnect: making Chromecast and Sonos speakers look like AirPlay targets

Two binaries, one job, no installation ritual

AirConnect is two C programs rather than a package with dependencies. `aircast` targets Chromecast devices and `airupnp` targets UPnP players including Sonos. Both do the same three things: scan the local network for supported players, create one virtual AirPlay device per player found, then act as a proxy sitting between AirPlay clients and the real hardware.

That design is the whole reason it is easy to run. There is no library to install and no service to register. You put the executable somewhere, make it executable, and run it. The README states plainly that nothing else should be required, no library or anything to install, and that on non-Windows and non-macOS platforms you relaunch with `-z` to daemonize and close the terminal.

The platform list is long and specific: Windows, macOS on both x86 and arm64, Linux on x86, x86_64, arm, aarch64, sparc, mips and powerpc, plus Solaris and FreeBSD. Crucially, it does not have to run on your main computer. A Raspberry Pi is the case the README names, which matters because AirConnect has to sit on the same network segment as the speakers, and a Pi is a cheap way to keep it there permanently.

Version 1.11.3 is the current tag, published 2026-09-06, with 1.11.2 in August 2026 and 1.11.1 earlier that month. The last push matches the newest tag. The project is written in C, has 4187 stars and 251 forks, 49 open issues, and is not archived.

Getting the binary and dealing with static versus dynamic builds

Prebuilt binaries ship as a zip named for the version, and the README documents both a manual download and a scripted route. A contributor has written an install and update script under the `updater/` directory of the tree:

wget https://raw.githubusercontent.com/philippe44/AirConnect/master/AirConnect-<X.Y.Z>.zip

Inside, the naming convention tells you which binary you want. For Chromecast it is `aircast-<os>-<cpu>`, for example `aircast-macos-x86_64`, and for UPnP or Sonos it is `airupnp-<os>-<cpu>`, for example `airupnp-macos-arm64`. Once you have picked one, the executable bit is the only setup step:

chmod +x <executable>

The static versus dynamic choice is where most first-time installs get stuck, and the README is unusually candid about it. Each platform ships a normal build and a `-static` build with all libraries linked in, including SSL. Using the static build is described as really not recommended unless the regular version fails. The catch is that the regular build on macOS needs OpenSSL, which means installing it with `brew install openssl` and then symlinking the resulting dylibs into place so the loader can find them:

ln -s /usr/local/opt/openssl[/x.y.z]/lib/libcrypto.dylib /usr/local/lib/libcrypto.dylib
ln -s /usr/local/opt/openssl[/x.y.z]/lib/libssl.dylib /usr/local/lib/libssl.dylib

For Windows the equivalent friction is the Microsoft VC++ redistributable plus two DLL files placed next to the exe. The README also links to separate guidance on forcing glibc versions for old systems, and asks you to open an issue if static linking still does not work, which is the point at which this project stops being simple.

Decoded ALAC out, optionally re-encoded for metadata

The audio path explains most of the behaviour you will notice. AirPlay clients send ALAC, AirConnect decodes it, and then either passes the audio through in plain form or re-encodes it using mp3, aac, flac, wav or pcm.

The reason to re-encode is metadata, and the README is specific about the limits. Most players will not display artist, title, album or artwork, except when mp3 or aac re-encoding is used and the target is an UPnP or DLNA device that supports the icy protocol. Chromecast players gained that support after version 1.1.x. So if you want the album art from iTunes to show up on your speaker, the codec flag is doing real work rather than being an audio quality knob.

The flag is `-c`, and the accepted syntax is unusually fine-grained: `-c mp3[:<rate>]|aac[:<rate>]|flac[:0..9][/1152...16384]|wav|pcm`. FLAC therefore takes a compression level from 0 to 9 and an optional window size, and mp3 and aac take an explicit rate. That level of control suggests the author has been tuning against specific players that misbehave at the defaults.

Two other transport details matter for troubleshooting. Volume changes made in the native control application are synchronized back to the AirPlay client, so a Chromecast volume adjustment moves the iPhone's volume too. And using pause, stop, next or previous from the native app sends that command to the AirPlay client instead, which means once you pause, control passes back to the phone. Reading the audio path makes both of those behaviours predictable rather than mysterious.

Ports, firewall rules and running it in the background

The networking instructions are the part to follow exactly, and the README's advice is to not open ports manually. UDP 5353 is required so the process can listen for mDNS discovery. Beyond that, each device permanently occupies one port for RTSP, and while audio is playing it adds one port for HTTP and three for RTP.

Those extra ports are allocated from a range you can control with `-a <port>[:<count>]`, where the default count is 128. The HTTP transfer mode has its own flag, `-g`, accepting `-3` for chunked, `-1` for no content-length, and `0` for a fixed dummy length. That last option is a workaround rather than an optimization, and the README explains the reasoning around HTTP content-length separately, which is a sign these modes exist for specific player implementations that misparse the response.

UPnP adds one more port for discovery, controlled by `-b`, defaulting to 49152, and the README notes a user-supplied value must be above that. The `-b` flag has a second job: with multiple ethernet cards you use it to choose which interface to bind to, and 0.0.0.0 is explicitly not allowed. There is also `-u <version>` to cap the maximum UPnP version searched.

For daemonizing, `-z` disables interactive mode and self-daemonizes, with `-p <file>` writing a PID, while `-Z` only disables interactive mode. An `airupnp.service` file at the repository root gives you a systemd unit to adapt. In Docker the README is unambiguous: you must use host networking mode, and you cannot have NAT between your devices and the machine running AirConnect.

Command-line options worth knowing before you tune anything

The README defers to `-h` for full command line detail, but several options are worth knowing in advance because they change how the tool behaves rather than merely how it is named.

For Sonos and Heos players specifically, the README tells you to set a latency range on the command line, giving `-l 1000:2000` as the example and running it as `./airupnp-macos -l 1000:2000`. That is presented as a Sonos and Heos requirement rather than a tuning option, so it is worth applying before diagnosing any audio trouble.

Device naming has its own flag, `-N`, taking a C-style format string where `%s` is the player's name. The default is the player name followed by a plus sign, which is a good choice because it makes bridged devices visibly distinct from real ones in the AirPlay picker.

Two features are narrower. `-S <broadcast[radio|track>` enables a streaming mode for Sonos players, so the angle bracket in the documented syntax is a typo in the README rather than something you type. And Chromecast groups are supported, with `-v` setting a media volume factor for all devices in the group, defaulting to 0.5, which keeps group playback from overwhelming a room.

Interactive mode is worth a mention too. Without `-z` or `-Z` you get a prompt where you can type `exit` to quit or `save <file>` to write the current configuration to a named file. A default `config.xml` can also be created for advanced tweaking, and the README says a reference version can be generated with `-i <file>`. Since players are re-scanned for new or lost devices every 30 seconds, a discovery issue usually resolves itself, which is worth knowing before you start opening firewalls.

The build side of the repository is minimal: a `build.sh`, a `buildall.sh` for every platform, a `build.cmd` for Windows, and a `common/` directory shared by the two applications. The AirConnect zip is also committed at the repository root, so the binary distribution and the source live in the same place.

Editorial conclusion

AirConnect is a good fit when you have committed speakers and you want iPhone playback to reach them, and a poor fit if your problem is video, because everything here is an audio path with ALAC decoded and optionally re-encoded. Two things to check before you install it. The repository reports its licence as unasserted while a LICENSE file sits in the tree, so open that file rather than assuming terms from a topic list. And the daemon is unauthenticated on a local network, listening for mDNS on UDP 5353 and creating RTSP, HTTP and RTP ports per device, which means you should decide deliberately whether it belongs on a trusted segment. Start with `airupnp` on a Raspberry Pi with a Sonos pair, set latency with `-l 1000:2000` as the README shows, and leave the firewall rules alone until you understand which ports it opened.

Frequently asked questions

Official sources

1. Issues
2. philippe44/AirConnect on GitHub
3. README
4. Releases