AirPipe FAQ

First, make sure audio is actually playing on your phone. AirPipe only forwards audio the phone is currently producing.

If audio is playing on the phone but the speaker stays silent:

The most reliable fix: restart your phone. Android sometimes blocks apps from being captured by other apps, and a restart clears that block every time.

Two more things worth checking:

1. The speaker's hardware volume. AirPipe controls a per-speaker software volume; the physical knob still applies.
2. A different source app. Some apps block capture specifically. Firefox, VLC, or Pocket Casts are reliable test cases.

Update Spotify to a recent enough version.

• 9.1.42 (August 2025) and newer allow capture and work with AirPipe.
• 9.0.66 and earlier block capture by manifest. Update via the Play Store fixes it.
• Want to use an older or modded version? ReVanced's "Remove screen capture restriction" patch re-enables capture for Spotify and several other apps that opt out by default.

After updating, fully close Spotify (swipe it out of recents) before starting a new AirPipe stream.

Android sometimes adds apps to a system-wide "no capture" list as you use your phone. Once an app is on the list, AirPipe receives silence.

The reliable fix: restart your phone. It clears the list every time.

If you'd rather try something less disruptive first:

1. Stop the stream and start it again with a different source app. If only one app is affected, this gets you past it.
2. Force-stop the source app in Android Settings. Can shake its track loose.
3. Restart your phone if the steps above don't help.

This is an Android limitation, not an AirPipe bug. We've reported it to the Android team.

Reliably works in our testing: Firefox, Samsung Internet, VLC, MX Player, YouTube, Pocket Casts, Audiobookshelf, Plexamp, most games.

Sometimes works (audio drops after a while, restored by a phone restart): Spotify, Chrome, Telegram, apps that embed common media SDKs.

Doesn't work out of the box: DRM-protected services like Netflix, Disney+, Prime Video, Apple Music, and Tidal.

For apps that block capture by manifest, ReVanced and similar tools can patch the restriction off if you're comfortable sideloading.

Almost every capture failure clears with a phone restart (see above). If a restart does not bring the audio back, the app is blocking capture deliberately, and nothing on the phone will change that.

There are two cases:

1. DRM-protected content. Streaming services like Netflix, Disney+, Prime Video, Apple Music, and Tidal protect their audio so other apps can't capture it. AirPipe can't work around this.
2. Apps that disable capture at build time. Some apps opt out of capture in their manifest. An older or modded build can do this even when the current Play Store version allows capture.

For a DRM-protected service there is no AirPipe-side fix. For an app that opted out by manifest, updating to the current Play Store version, or using a build that allows capture, is the only path.

This is a source-app and Android limitation, not an AirPipe bug.

AirPipe speaks both AirPlay 2 and AirPlay 1 (RAOP) and picks the best protocol for each speaker automatically. If an AirPlay 2 connection isn't possible, AirPipe falls back to AirPlay 1 on its own; there is nothing to configure.

Tested and reliable: Bose Portable Home Speaker, Sony Bravia Theater Bar, shairport-sync (Raspberry Pi and other Linux hosts), Music Assistant, and a Mac as an AirPlay receiver (see below).

Most modern AirPlay 2 speakers and soundbars from brands like Sonos, Marshall, Bluesound, Denon HEOS, Bose, and Sony work with AirPipe.

A Mac can be a speaker too. Enable AirPlay Receiver on the Mac and set "Allow AirPlay for" to "Anyone on the same network". Each time you connect, macOS asks for permission: a banner appears in the top-right corner of the Mac's screen, and you have about 15 seconds to click Accept while AirPipe shows "Waiting for approval on the device…". If the banner expires, connect again and a fresh one appears. With the "Current user" setting AirPipe cannot connect, because the Mac then only admits senders signed in to the same Apple ID; use "Anyone on the same network" instead.

HomePod, HomePod mini, and modern Apple TV are not supported yet. They are close relatives of the macOS receiver, and our Mac testing showed that this receiver family needs connection handling AirPipe currently enables only for Macs. We don't claim support we haven't verified on a real device. If you have a HomePod and want to help us test, we'd like to hear from you.

That speaker's AirPlay security setting only admits senders that complete Apple Home (HomeKit) pairing, which AirPipe doesn't support yet.

If it's your speaker, you can open up access in Apple's Home app on an iPhone or iPad: select the speaker, open its settings, and set Allow Speaker & TV Access to Anyone on the Same Network (or Everyone). If the speaker uses a password instead, remove the password. AirPipe connects normally afterwards.

It selects how AirPipe wraps the audio it sends to your speakers. Both options are lossless, the audio quality is identical in either case.

• On (default) sends compressed ALAC, about 440 bytes per packet. This is what almost every modern AirPlay receiver expects, so it offers the broadest compatibility and works best on weak Wi-Fi.
• Off sends uncompressed ALAC, about 1412 bytes per packet. The audio is exactly the same, the packets are just larger and less efficient on the wire.

When to flip it off: if a specific speaker plays cleanly from other AirPlay senders but produces choppy or distorted audio from AirPipe, try disabling this setting. Some receiver decoders mishandle compressed ALAC and the uncompressed path can recover them.

The change takes effect on the next stream you start, not on a stream that's already running. If you're currently streaming, stop and start it again for the new setting to apply.

No. Audio goes only to the AirPlay speakers you select, over your local Wi-Fi.

• Nothing transits the internet.
• Nothing is recorded, stored, or analyzed.
• No analytics, no cloud, no telemetry.

Audio is encrypted in transit on the AirPlay 2 path with ChaCha20-Poly1305. On the AirPlay 1 (RAOP) fallback, encryption depends on the receiver: legacy AirPlay 1 receivers negotiate AES-128-CBC with an RSA-OAEP-wrapped session key, while most modern AirPlay 2 receivers accept the fallback stream unencrypted. Either way, audio stays on your local network.

Android requires apps to request media-projection permission to access system audio. The prompt warns about screen capture as a generic safety message, but AirPipe never captures, stores, or transmits the screen image. Only audio is forwarded to your selected speakers.

The persistent notification while streaming is also required by Android for foreground services that use media projection.

AirPipe doesn't use the microphone. Android requires the RECORD_AUDIO permission as a prerequisite for the AudioPlaybackCapture API, the system mechanism that lets apps forward playback audio.

Granting it does not grant microphone access.

Most "no audio" cases trace back to the source app or the Android audio system, not AirPipe.

• We can't override another app's choice to opt out of capture.
• No app on the Play Store has access to system-level audio routing controls that would help.

We continuously test on real speakers (Bose, Sony, shairport-sync, Music Assistant) and ship fixes for the issues we can fix on AirPipe's side.

If you've worked through the relevant entries above and audio still isn't reaching your speaker, email us via the support address on the AirPipe Play Store page.

AirPipe is an Android app that forwards audio from your phone to AirPlay speakers using standard, well-documented system APIs. The full pipeline:

1. Discovery. AirPipe listens for mDNS and Bonjour announcements on your local Wi-Fi. AirPlay-compatible speakers advertise themselves automatically, so you never need to enter an IP address by hand.

2. Capture. Once you select a speaker and grant the system permission prompt, AirPipe uses Android's AudioPlaybackCapture API (introduced in Android 10) to receive a copy of the audio your phone is currently producing. The capture happens entirely inside the Android system; AirPipe receives only the resulting PCM stream. AirPipe runs as a foreground service so Android keeps the pipeline alive in the background, which is the persistent notification you see while streaming.

3. Encryption and transport. AirPipe packages the audio into RTP packets and sends them directly to the speaker over your Wi-Fi, using RTSP for control and RTP for audio. On the AirPlay 2 path the control channel and the audio packets are encrypted with ChaCha20-Poly1305 keys negotiated during pairing. On the AirPlay 1 (RAOP) fallback path, encryption depends on the receiver: legacy receivers negotiate AES-128-CBC with an RSA-OAEP-wrapped session key, while most modern AirPlay 2 receivers accept the fallback stream unencrypted.

4. Multi-speaker sync. When streaming to multiple speakers at once, AirPipe shares a single timestamped timeline across all destinations so playback stays in step across rooms.

What we do with the audio: nothing beyond forwarding it. It is never recorded, never written to disk, never uploaded anywhere, and never analyzed for content, songs, or metadata. It never leaves your local Wi-Fi network. There are no analytics, no cloud services, and no telemetry inside AirPipe.

The audio path is phone to speaker. Nothing in between is controlled by us.