airplay-esp32: an AirPlay 2 receiver on a ten dollar board

An AirPlay target that never talks to a server

The pitch in the README is a cheap ESP32 board turned into a wireless AirPlay 2 speaker: plug it into any amplifier or powered speakers and it shows up on an iPhone, iPad or Mac just like a HomePod or an AirPlay TV. The line that sums up the design is short. No cloud, no app, just tap and play. That matters for the AirPlay 2 protocol, which pairs a device with a receiver and then streams directly between them, so a receiver that implements the protocol properly does not need a server in the middle at all. The project says it is an independent project based on protocol analysis, and it is not affiliated with Apple, and it is not guaranteed to work with future iOS or macOS versions, which is the honest caveat for anything built this way.

The project is written in C, its default branch is main, the licence is a custom non-commercial one, and the documentation site is rbouteiller.github.io/airplay-esp32/. The last push to the repository was on 2026-10-16, which is also the date of the most recent tag, a beta build, 0.3.0-beta.b215aa9, with the previous releases v0.2.1 from 2026-09-20 and v0.2.0 from 2026-08-23.

The chips and the boards that already have an amplifier

The supported hardware list is where the practical detail sits. It works with ESP32, ESP32-S2, ESP32-S3 and ESP32-C5 chips, and the README names two boards with amplifiers built in, the SqueezeAMP which is an ESP32 with a TAS5756, and the Esparagus Audio Brick which is an ESP32 with a TAS5825M. Those two are the difference between plugging in a speaker cable and soldering to a board.

The Bluetooth fallback is narrower than the AirPlay support, and the README is specific about it: ESP32-based boards also support Bluetooth A2DP, so anything that can pair with a Bluetooth speaker can play to them when AirPlay is idle. So the Bluetooth path is the fallback rather than the primary path, and the S2 and S3 class parts are the ones covered. The Esparagus Audio Brick additionally supports wired Ethernet through an optional W5500 module, which is the one case where the board can be on a network that is not WiFi, with automatic WiFi failover as the safety net.

The features list also covers output, displays and controls: 48 kHz output with optional 44.1 to 48 kHz conversion via a sinc resampler, optional OLED or 320x170 colour TFT with track metadata, and optional play/pause, volume and track skip buttons. The documentation splits these into separate pages, one for Bluetooth and Ethernet, one for displays and buttons and AirPlay tuning.

Two ways to flash it, and the SPIFFS step that is not optional

The quickest route is the browser installer, which the README describes as needing no toolchain and no command line. If you would rather build from source, the commands are three, and the second one carries a comment that is easy to skim past.

git clone --recursive https://github.com/rbouteiller/airplay-esp32
cd airplay-esp32
pio run -e esp32s3 -t upload
pio run -e esp32s3 -t uploadfs   # required — writes the web UI to SPIFFS

The clone needs the --recursive flag because the repository has a .gitmodules file and submodules that have to be present. And the uploadfs step is marked required, because it writes the web interface into SPIFFS, the flash filesystem, which is where the configuration page and the OTA update mechanism live. Skip it and the device boots without a web UI. The repository also carries a platformio.ini for the PlatformIO build environments, a CMakeLists.txt, a config/ directory, a main/ directory, components/, scripts/, a version.txt and a dependencies.lock.

If you are assembling the hardware rather than buying a ready board, the shopping list is an ESP32-S3 dev board, a PCM5102A DAC and a female pin header, roughly ten dollars in total, and the README says no soldering. The DAC is there because the ESP32 has no analogue audio output worth using, so the digital stream has to leave the chip through a converter.

What the AirPlay 2 implementation actually covers

The AirPlay 2 feature list is short and the first entry is the compatibility claim that matters. The device appears natively in Control Center and in every AirPlay-capable app, which is the difference between a receiver that works and one that requires a third party app on the sending side. Decoding covers ALAC and AAC, so both the lossless path and the compressed path work, and the README says that covers live streaming, so Siri and calls, as well as music playback. Multi-room is implemented with PTP-based timing for synchronised playback, which is a real AirPlay 2 feature rather than a set of independent speakers that happen to play together.

The acknowledgements tell you where the knowledge came from. Shairport Sync is named as the reference AirPlay implementation, openairplay/airplay2-receiver as a Python AirPlay 2 implementation, and Espressif for the ESP-IDF framework and codec libraries. That is an unusual and useful combination: a mature C reference implementation for the protocol, an existing Python AirPlay 2 implementation to compare against, and the chip vendor's own codecs.

The scope limits are stated in the same breath as the features. Audio only, one speaker per board, and a decent WiFi signal is required. There is no video, there is no multi-device coordination on a single board, and the WiFi requirement is the one most likely to cause a bad first experience, because AirPlay drops out on a weak link long before the audio quality is compromised.

Web configuration, OTA updates and the ESP-IDF base

Two operational features make this deployable in a place where a USB cable is inconvenient. Web configuration means the device is set up from a browser on the network, and OTA updates mean a firmware change is pushed to the board the same way, with the README noting that USB is only needed for the first flash. The troubleshooting page in the documentation covers no sound, no setup WiFi, dropouts and build errors, which is a fair map of what goes wrong with a device like this.

The build is based on ESP-IDF, with the README badge showing ESP-IDF v5.5+ as the requirement, and there is a reference page for build environments, SPIFFS, OTA and architecture. The contribution process is documented in CONTRIBUTING.md and a separate contributing guide, and the documentation itself lives in docs/ and is built with Zensical, with an edit link on every page that goes straight to the GitHub editor.

The development scripts are visible at the top level too, with scripts/, a .clang-format and a .clang-tidy for the C sources, a requirements-dev.txt, and a .githooks/ directory, so a contributor is expected to run the project's own formatting and linting rather than their own defaults.

Where a $10 AirPlay target is the wrong answer

Three cases point elsewhere. The first is commercial. The README is explicit that this is non-commercial use only, that commercial use requires explicit permission, and the licence file is the binding document, so any product that would ship this firmware needs a different arrangement and this is a licensing conversation rather than a technical one. The second is a house with more than one room of audio. The multi-room feature is PTP-based synchronised playback, which is not the same as a coordinated speaker group that you can move between rooms, and the one speaker per board limit means the topology of the audio has to be designed around separate boards rather than grouped ones.

The third is a house with poor WiFi, and this is worth dwelling on because the failure is confusing rather than obvious. AirPlay streams over the network, so a weak signal produces dropouts and stuttering rather than an error, and the troubleshooting page lists dropouts as a category, which tells you the project knows about it. On the same network, a vendor receiver with Ethernet and a better antenna will simply not have the problem.

The alternative to weigh is Shairport Sync, which the README names as the reference AirPlay implementation, and the difference in approach is exactly the one this project trades away. Shairport Sync runs on a Linux single board computer with a real network stack and real audio hardware, so it is more expensive, more power hungry and more flexible, and it also needs the code running rather than firmware on a microcontroller. airplay-esp32 wins on cost, on size and on having no operating system to maintain, and loses on the parts of AirPlay that need real compute.

Editorial conclusion

airplay-esp32 fits a maker who wants an AirPlay 2 target on a shelf without buying a HomePod, and who is comfortable with a board, a DAC and a flashing step, or with a browser-based installer that avoids a toolchain entirely. It does not fit a commercial product, since the licence restricts use to non-commercial purposes without explicit permission, and it does not fit a multi-room home, since it is one speaker per board with multi-room timing rather than a coordinated group. Before you commit, read the LICENSE file, because that is the binding constraint on everything else here, and check the supported boards page, since the amplifier-equipped boards behave differently from a bare dev board.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. rbouteiller/airplay-esp32 on GitHub
4. README
5. Releases