Casting audio from your phone to your hi-fi: AirPlay, Chromecast and Bluetooth compared

I'll be straight with you: I spent most of the last decade being deeply snobbish about wireless audio. Running a record shop on Smith Street in Fitzroy will do that to you. The ritual of pulling a record, cleaning it, dropping the needle — it's a complete thing, and the idea of casting a Spotify playlist to my amp felt a bit like ordering a flat white and asking for it in a paper cup. But then I installed a streamer in my kitchen, another in the listening room, and found myself actually using them every day. And once you start caring about how the signal gets from your phone to the speakers, you fall down a different kind of rabbit hole.

This one is about casting protocols specifically: AirPlay 2, Google Cast (often called Chromecast Audio), and Bluetooth. Three wireless paths, three very different architectures, and real differences in what they deliver to your ears. I'll try to cut through the marketing and tell you what actually matters.

Why the protocol matters more than most people think

Most people assume wireless audio is wireless audio. It isn't. The protocol defines how audio is encoded for transmission, how the receiving device handles buffering and decoding, and — critically — whether your phone is doing the heavy lifting or the streaming device is.

That last point is the one most people miss. With Bluetooth, your phone encodes the audio and beams it continuously to the receiver. With AirPlay 2 and Google Cast, you're handing off the stream: your phone tells the device what to play, and the device then fetches and decodes the audio itself. The phone becomes a remote control, not a transmitter. That distinction has real implications for quality, reliability and battery life.

Bluetooth: the universal translator

Bluetooth works everywhere, with almost everything. That's its genuine strength. Any phone, any Bluetooth receiver, no network required. For a lot of people — especially those listening in a single room on a portable speaker or a budget system — it's perfectly adequate.

The limitation is codec-dependent. The mandatory codec for Bluetooth audio is SBC, which is adequate but not spectacular: it's a lossy format with variable quality depending on the implementation. If both your phone and your receiver support aptX HD or LDAC, you're in genuinely good territory — LDAC in particular can carry up to 990 kbps, which is more than enough bandwidth for CD-quality audio and, in theory, for hi-res. In practice, LDAC at maximum bitrate can be finicky on congested 2.4 GHz spectrum, and most implementations drop to 660 kbps or even 330 kbps under pressure.

The other issue with Bluetooth is latency. It's real, it's variable, and whilst it rarely matters for pure music listening, it matters enormously if you're trying to sync audio across rooms. Multiroom Bluetooth is essentially not a thing at the serious end — the protocol wasn't designed for it.

My honest view: Bluetooth is fine for the kitchen, the bathroom, the workshop. I wouldn't build a listening room around it.

AirPlay 2: Apple's network audio protocol, with some caveats

AirPlay 2 is a proper network protocol. When you AirPlay to a receiver, your iPhone or Mac hands off a reference to the stream (or the file), and the receiving device connects to your network to fetch or decode it. Your phone is freed up; the audio path runs over your local network via TCP/IP, with buffering and error correction that Bluetooth can't match.

Audio quality over AirPlay 2 is transmitted as 16-bit/44.1 kHz ALAC (Apple Lossless Audio Codec). That's CD-quality, lossless. Not hi-res, but genuinely lossless. From a signal-integrity standpoint, what arrives at your DAC is bit-perfect to the source, assuming you're playing 44.1 kHz material. Apple Music's lossless tier streams ALAC natively, so the chain from the streaming service to your DAC via AirPlay 2 is lossless end-to-end — that's a meaningful thing.

The multiroom implementation in AirPlay 2 is also genuinely well done. Apple rebuilt the sync architecture specifically to handle multiple zones playing simultaneously. It works, and it works reliably, which is more than I can say for some alternatives I've tested.

The obvious limitation is the Apple ecosystem. AirPlay 2 is available on a reasonable number of third-party receivers these days — the Cambridge Audio CXN100 (check price) supports it, as does the WiiM Ultra (check price) — but you need Apple hardware on the sending end. Android users are out. And Apple's grip on the protocol means it evolves on Apple's timeline, not yours.

Google Cast: the platform-agnostic network alternative

Google Cast (the underlying protocol behind Chromecast Audio and Cast-enabled speakers) works on the same principle as AirPlay: the receiver fetches the stream itself rather than relying on your phone for continuous transmission. It's available on both Android and iOS, which gives it a genuine cross-platform advantage.

Audio quality over Google Cast is where it gets interesting — and, honestly, a little inconsistent. The protocol itself supports lossless transmission, and when you're casting from certain apps (YouTube Music, Tidal, some others) the path can be lossless or near-lossless depending on the app's implementation. But Google Cast's audio quality ceiling varies by app. Spotify's Cast implementation, for example, has historically maxed out at 320 kbps Ogg Vorbis — lossy, though at 320 kbps it's very good lossy. Tidal's Cast implementation can carry FLAC. So the practical quality you get depends on which app you're casting from, not just the protocol itself.

This is my main frustration with Google Cast at the serious audio level: the quality ceiling is app-defined, not protocol-defined, and it varies in ways that aren't always transparent to the user. You need to know what your specific app is sending.

Multiroom with Google Cast works well in practice. Google's Home ecosystem handles multi-zone grouping competently, and latency sync has improved significantly in recent years. If you're an Android household and you want network-quality multiroom, Cast is your most practical path.

What happens at the DAC end

Something I don't see discussed enough: once the signal arrives at your streamer or receiver, the quality of the local DAC and output stage matters as much as the protocol used to get it there. A lossless AirPlay 2 signal into a mediocre DAC still sounds like a mediocre DAC. The protocol gives you the ceiling; the hardware determines whether you reach it.

If you're building a proper listening system, the streamer's DAC quality — or the quality of a separate DAC you connect to it — is where I'd focus attention after you've sorted the network path. Our guide to the best DACs and network streamers goes deeper on that, and it's worth reading alongside this one. A device like the WiiM Ultra (check price) punches well above its price on both network protocol support and internal DAC quality — it supports AirPlay 2 and Google Cast simultaneously, which removes the protocol choice entirely for most setups.

For those integrating a streaming source with an existing amplifier, our guide to streaming amplifiers and all-in-one systems covers the integrated options if you'd rather not add a separate box.

Practical matching: which protocol for which setup

If your household is entirely Apple — iPhones, Macs, Apple Music — AirPlay 2 is the tightest, most reliable choice. The lossless path is genuine, multiroom sync is solid, and you get Siri integration if you want it. The caveat is that guests with Android phones won't be able to cast. In my listening room at home, I run AirPlay 2 as the primary path for exactly this reason.

If you're mixed Android/iOS or you want a protocol that any visitor's phone can use, Google Cast is more practical. The quality is good to very good depending on app, and the ecosystem is extensive. I'd just make sure you understand what your preferred streaming apps are actually sending over Cast before assuming lossless delivery.

Bluetooth makes sense as a fallback for guests, for portable speakers, and for any situation where network access isn't available or practical. In a dedicated listening setup, I'd treat it as the third option rather than the primary one. The codec gap matters less than people think at normal listening levels, but the inability to do reliable multiroom and the continuous-transmission architecture make it less elegant as a permanent solution.

One more thing worth knowing: many modern streaming receivers support all three simultaneously. There's no rule that says you have to pick one. The Cambridge Audio CXN100 (check price), for instance, supports AirPlay 2, Chromecast and Bluetooth in the same box. Pick your protocol by the source device at hand.

A word on network infrastructure

The one thing that undermines both AirPlay 2 and Google Cast more than anything else is a poorly configured home network. Both protocols rely on mDNS (multicast DNS) for device discovery, and many consumer routers handle multicast traffic badly — especially if you have a mesh network with multiple access points, or if your network uses VLANs to separate IoT devices from your main network.

If your streamer keeps disappearing from the app, or audio drops intermittently, the protocol is rarely the culprit. Nine times out of ten it's multicast traffic being dropped somewhere on the network. Our existing piece on Wi-Fi versus Ethernet for network streamers covers the infrastructure side in detail — worth a read if you're having reliability issues.

Wired Ethernet to the streaming device eliminates most of these problems outright. It's not glamorous advice, but it's the right advice.

The thing nobody tells you about Bluetooth codec negotiation

One genuinely frustrating thing about Bluetooth audio: codec negotiation happens automatically between your phone and the receiver, and it isn't always obvious which codec actually connected. Your phone might support LDAC, your speaker might support aptX HD, and they'll fall back to SBC because one of them decided the signal was marginal. On Android you can expose the active codec in Developer Options; on iOS you can't without third-party tools.

If you're investing in a Bluetooth receiver specifically because it advertises LDAC or aptX HD support, it's worth verifying that the codec you expect is actually the one connecting. On Android: Settings > Developer Options > Bluetooth Audio Codec. It's a small thing, but I've seen people pay for high-codec receivers and connect via SBC for months without realising it.

The Bluetooth SIG maintains published specifications for each codec if you want to go deeper on the technical side — their documentation on the Bluetooth SIG resource library is dry but accurate. For a more approachable breakdown of hi-res audio formats more broadly, the Qobuz editorial on hi-res audio formats is a reasonable starting point.

Anyway. I still put a record on most evenings. But the streamer in the kitchen is on every morning, and it's AirPlay 2 into a decent DAC, and it sounds genuinely good. The ritual is different — tap, wait, play — but the sound arriving at the speakers doesn't know how it got there.

— Priya Anand, Vinyl & Valves Editor