SBC vs AAC vs aptX Latency: Sourced Numbers

There is no single honest answer to SBC vs AAC vs aptX latency, because the published figures overlap and contradict each other. The usable summary: SBC and AAC both land somewhere in the low hundreds of milliseconds, aptX Low Latency is quoted at about 40 ms, and an iPhone can only ever use AAC or SBC.

This page is the reference table. Every number is attributed to whoever published it, and where two sources disagree, both numbers are printed instead of one average. Averaging two conflicting claims produces a number nobody measured.

The published figures, with sources attached

Codec latency is the encode-plus-decode cost of the audio format itself. It is one term in a longer sum, which the next section pulls apart. Here is what the sources actually say.

Two entries are deliberately absent. Plain aptX, without the Low Latency suffix, is quoted at figures I have not been able to tie to a primary source, so it is not in the table. LDAC is the same story: Sony's high-bitrate codec has widely repeated latency claims and no figure I trust enough to publish. Neither omission costs an iPhone owner anything, since iOS supports neither.

The only number that describes your gear is the one you measure. The site's browser round-trip latency test plays a 30 ms chirp, records it back through the microphone, cross-correlates the two, repeats five times and reports the median with the speed-of-sound travel time already subtracted. That result includes the codec, the receiver's buffer, and your phone's own audio stack, which is what you feel in the room.

SBC vs AAC vs aptX latency: where the sources fight

SBC is the clearest example of a codec latency comparison that refuses to converge. One body of sources quotes 100-150 ms. Another quotes 150-300 ms. Both are published in good faith, and both are probably right about the hardware in front of them, because SBC is not one configuration. It is a bitpool range, a block size, and a bitrate that the transmitter and receiver negotiate on connection. A cheap speaker with a deep safety buffer and a laptop with an aggressive one are running the same codec name and nothing like the same delay.

AAC latency has a narrower published spread, roughly 100-200 ms, but the same caveat applies. Apple's AAC encoder is not the encoder in a generic Android transmitter, and nothing obliges two speaker manufacturers to use the same decoder or the same jitter buffer size. Those are private engineering choices, disclosed in neither the box nor the spec sheet, so two speakers running the same codec can still differ by a wide margin. That is the reason a measurement of your own gear beats any published table, including the one above.

aptX Low Latency is the outlier that gets quoted most often and applies least often. Qualcomm's roughly 40 ms figure is real, and it requires an aptX LL transmitter talking to an aptX LL receiver. Two devices, both licensed, both in the same mode. Break either half of the pair and you fall back to AAC or SBC and the whole advantage disappears.

What an iPhone actually uses

An iPhone offers SBC and AAC. It has no aptX support at all, in any variant, and there is no setting, profile, or app that adds it. That single fact resolves most of the codec debate for anyone reading this on an Apple device: the aptX column is trivia. The longer version, including why the "aptX compatible" sticker on a speaker box changes nothing, is in the guide on whether iPhone supports aptX Low Latency.

So the practical iPhone question is narrower than the internet's question. It is not "which codec should I choose", because you do not choose. It is "how much delay is my particular speaker adding on top of AAC", and that is measurable rather than arguable.

LC3, LDAC, and the codecs people ask about next

LC3 is the codec of Bluetooth LE Audio, and the Bluetooth SIG puts it at roughly 20-30 ms. That is a genuine generational improvement, low enough to sit under the threshold where most people stop noticing delay. It also needs LE Audio on both ends of the link and a use case that routes through it, which a phone microphone feeding a five-year-old party speaker is not. Treat LC3 latency as the shape of the future rather than a fix for tonight.

LDAC latency comes up constantly in the same breath. It is Sony's high-bitrate codec, it is aimed at bitrate rather than delay, and iOS does not support it. Anyone promising you a lower-latency iPhone microphone through LDAC is describing a device that does not exist.

Codec latency is not your total delay

This is the part that makes single-number codec comparisons misleading. The delay you hear between your mouth and the speaker cone is a stack:

• Input buffering. The phone collects microphone samples in blocks before anything can process them. In the app that prompted this site, that block is 2048 samples.
• Processing. Gain, filters, any effect. On a modern iPhone this is small but not zero.
• Encode. The codec's own cost, the number in the table above.
• Radio transmission. Small, and mostly retransmissions when the link is congested.
• Receiver buffer. Often the single largest term, and never published. A speaker built for music playback holds a deep buffer on purpose so a dropout never becomes an audible gap.
• Decode and analogue output. Small.

Two speakers running identical AAC can differ by more than the entire published AAC range, purely on buffer policy. That is why the numbers in reviews so rarely match what you get, and why the broader guide to Bluetooth microphone delay keeps steering people back to measurement.

What these numbers feel like in a room

Rough perceptual landmarks, which matter more than the codec names: under about 20 ms, delay goes unnoticed. Around 40-50 ms, lip sync starts to look wrong on video. Past about 100 ms it feels like a bad phone call, and speaking into it becomes actively difficult, because hearing your own delayed voice disrupts speech in a way passive listening never does.

Put the table next to that scale and the picture is blunt. Every Bluetooth codec an iPhone can use lands in or above the range where a live talker notices. There is more detail on the thresholds, and on why singers suffer more than presenters, in how much audio delay is actually noticeable. If the material is music with a beat, the karaoke-specific guide covers the workarounds that genuinely help.

The HFP trap that changes the comparison

All of the figures above assume A2DP, the stereo music profile. A Bluetooth link carries one profile at a time, so the moment something asks a headset for its microphone, the link drops A2DP and switches to HFP, the narrowband headset profile. Sound quality collapses to something like a phone call, and iOS gives you no control over the switch. The mechanics are covered in why Bluetooth audio quality drops when the mic turns on, and you can hear it happen in the browser microphone test, which reports the sample rate the browser is actually receiving.

This is the strongest argument for the architecture this site is built around. Keeping the microphone on the phone and sending only playback over Bluetooth leaves the link in A2DP, so the speaker keeps its full bandwidth. It does not make the delay smaller. It makes the sound that arrives after the delay worth listening to.

If latency is the thing that matters most

Then stop optimising codecs and change the transport. A cable is the honest answer: a 3.5 mm lead from the phone into the speaker's aux input takes the radio out of the chain entirely, and the comparison is laid out in wired versus Bluetooth microphone latency. Dedicated 2.4 GHz wireless microphone systems come in under 20 ms and are not Bluetooth in any sense. Neither answer is what most people want to hear, and both are true.

If you are running more than one speaker, the gap between them is its own problem with its own numbers, covered in two Bluetooth speakers out of sync. And if you would rather hear the effect of gain and filtering before you worry about milliseconds, the live mic monitor runs entirely in the browser. The rest of the reference material is indexed with all the guides.