Bluetooth Audio Latency by Codec
You skip back ten seconds in a video and the mouth still moves a beat ahead of the words. Or you are three rounds into a game and every shot lands a fraction after you watch it connect. Both are the same fault, and it is not your headphones being cheap: audio sent over Bluetooth arrives late by an amount nobody in the chain is obliged to tell you, and the codec printed on the box explains only a small part of how late.
What follows is what each codec's owner publishes, what independent measurement found, and — where neither exists — a plain statement of that. Many circulated figures are neither.
What each codec publishes, and what has been measured
Two different quantities get called "codec latency". One is algorithmic delay: the audio a codec must see before it can emit anything, which is a property of the codec itself. The other is end-to-end delay: what you actually experience, from the app to your ear. They differ by an order of magnitude. The table separates them where the sources allow.
| Codec | Typical latency | Bitrate | Where it comes from | Notes |
|---|---|---|---|---|
| SBC | No single figure. Algorithmic delay about 3–6 ms; 308 ms end-to-end average across four Android phones. | 328 kbps at bitpool 53, 229 kbps at bitpool 35 — the two profiles A2DP recommends. | Latency measured by SoundGuys. Bitpool figures from a community write-up paraphrasing A2DP, not from the specification itself. | Mandatory in A2DP, so it is the fallback everywhere. Bitpool is negotiated per connection, so two pairs of headphones can both "use SBC" and behave nothing alike. |
| AAC | No vendor figure. Algorithmic delay about 60 ms at 44.1 kHz; 369 ms end-to-end average on Android, the widest spread of the four codecs tested. | Up to 264 kbps over Bluetooth. | Measured by SoundGuys; algorithmic delay from the same community write-up. Apple publishes nothing. | The Android figure was the worst of the four and varied most between handsets. No comparable published iOS measurement exists, so "AAC is fine on an iPhone" is a reasonable inference, not a cited fact. |
| aptX | Qualcomm publishes no latency figure on its own aptX page. Algorithmic delay about 3–6 ms; 316 ms end-to-end average on Android. | 352 kbps at 48 kHz. | Bitrate from Qualcomm; latency from SoundGuys and the community write-up. | "aptX is the low-latency one" is reputation inherited from aptX Low Latency, which is a separate product. |
| aptX Low Latency | Approximately 40 ms, measured by Qualcomm from an adapter running the encoder. | Not published on that page; 16-bit audio. | Vendor specification (Qualcomm). | Quoted almost everywhere as 32 ms — but that is the codec's own algorithmic delay, while Qualcomm's 40 ms is an end-to-end figure from an adapter. The two are not the same quantity, so the "disagreement" is mostly people comparing them. Both ends must support it or the link silently falls back. |
| aptX Adaptive | "Low system latency approx. 80 ms". | 279–420 kbps, varying with conditions. | Vendor specification (Qualcomm). | Bitrate and latency both move at runtime by design, so the figure is a typical case rather than a ceiling. |
| LDAC | Sony publishes no latency figure. Algorithmic delay about 30 ms; 324 ms end-to-end average on Android. | 330, 660 or 990 kbps, switched automatically. | Bitrate from Sony; latency from SoundGuys and the community write-up. | Built to move bits, not to arrive early. The high-bitrate mode is the one most likely to need a deep buffer. |
| LC3 | No end-to-end figure from the Bluetooth SIG. It states frame intervals of 10 ms and 7.5 ms, which bound the codec's own contribution and nothing else. | 160–345 kbps. | Frame interval from the Bluetooth SIG; bitrate range via SoundGuys, citing the SIG. | LC3 runs on LE Audio, a different transport, so the A2DP measurements above do not carry across. Independent end-to-end figures are still thin. |
Why the published numbers disagree so much
The pattern in the table is hard to miss: the codec's own delay is single- or double-digit milliseconds, and the delay you experience is several hundred. Almost everything in between is buffering — the audio buffer in the operating system, the buffer in the Bluetooth stack, and the buffer in the receiver, which is the one nobody publishes. The most thorough public breakdown of A2DP puts it plainly: total delay depends heavily on the playback device, its chipset and its buffer.
That is why the receiver matters more than the codec name. In the same set of measurements, one handset averaged 244 ms across all codecs and another averaged 484 ms — a 240 ms gap with the same receiver on the other end. No codec in the table has a 240 ms spread between its best and worst entry. The phone, the chipset and the earbuds' own firmware move the number further than your choice of codec does.
The second reason is that vendor figures are measured on vendor hardware. Qualcomm's 40 ms for aptX Low Latency is stated for an adapter running the encoder in an embedded Bluetooth device — a purpose-built rig, not your laptop, your stack and whatever your earbuds do next. It is a real figure. It is just not a promise about your setup.
How much delay actually matters
Broadcast has an answer, and it predates Bluetooth. ITU-R Recommendation BT.1359-1 reports that for sound and vision, the thresholds of detectability are about +45 ms to −125 ms, and the thresholds of acceptability about +90 ms to −185 ms, where a negative value means the sound is late. People tolerate late sound far better than early sound, which is lucky, because late is the only thing Bluetooth does.
Set the measured figures against that. A 40 ms codec delay is below the threshold at which anyone notices. A 308 ms end-to-end SBC link is past the point where the mismatch is merely acceptable, by a wide margin. This is why "which codec" is the wrong first question: a good receiver on SBC will beat a badly buffered one on a low-latency codec.
What actually fixes lip-sync
Mostly, something already did. AVDTP 1.3 added a Delay Report command, which lets the receiving device tell the transmitter how late its audio will be. The transmitter then holds the picture back to match. That is the whole trick, and it is why a video app usually looks fine on the same headphones that ruin a game: the video player has a frame buffer it can stall, so it delays the image until the sound catches up.
A game has nothing to stall. The sound is a response to your input, so the delay sits between the trigger pull and the report, and pushing the picture back would push your own control back with it. This is a structural difference, not a tuning problem. If the delay bothers you in a game, the fixes are: use a wired connection, use a transmitter and receiver that both genuinely support a low-latency codec, or use whatever "game mode" your earbuds offer — which almost always means a shallower buffer, bought at the price of dropouts when the radio link gets busy.
On a television, look for the A/V sync or audio delay offset in the settings and shift the picture manually. On a desktop, a USB low-latency dongle usually beats the host's Bluetooth stack.
Why no browser test can measure this
No page in a browser can tell you your Bluetooth latency. A page hands samples to the audio system and loses sight of them. The browser exposes an output-latency estimate, but it comes from the operating system and does not reliably account for what happens after the samples leave the machine — which, on a Bluetooth link, is most of the delay. A page that reports a number here is reporting the operating system's guess, dressed up.
Measuring it honestly takes hardware outside the computer. The measurements quoted above used a microcontroller rig running Google's WALT latency app, with a hundred runs per handset per codec, precisely because software alone cannot see its own output.
What this site can do is tell you whether the link is working and what it is doing to the sound. The tone generator plays a known frequency you can sweep across the range, which is the fastest way to hear a receiver rolling off the top end or a connection dropping under load. If what you hear rolling off turns out to be your own ears rather than the codec, hearing range by age has the published numbers on where that top edge typically sits. If you want to understand what the codec is compressing in the first place, sample rate and bit depth covers the raw format underneath. And if the answer to Bluetooth delay turns out to be a cable, headphone impedance covers whether the wired pair you have in mind needs more than your phone can give it.
Every figure links to its source, and the provenance column names what that source is. Vendor specifications and independent measurements are not interchangeable.