Bluetooth Audio Latency by Codec
You skip back ten seconds in a video and the lips still move a beat ahead of the words. Or you're three rounds into a game and every shot lands a moment after you see it hit. It's the same problem both times, and it isn't because your headphones are cheap. Sound sent over Bluetooth arrives late, by an amount nobody along the way has to tell you, and the codec printed on the box only explains a small part of it.
Below is what each codec's owner publishes, what independent testing found, and, where neither exists, a plain note saying so. A lot of the figures floating around online are neither.
What each codec's makers say, and what's been measured
Two different things both get called "codec latency". One is the codec's own delay: how much audio the codec needs before it can send anything out, which is built into the codec. The other is the total delay: what you actually experience, from the app to your ears. They differ by a factor of ten or more, so the table keeps them apart wherever the sources allow.
| Codec | Typical latency | Bitrate | Where it comes from | Notes |
|---|---|---|---|---|
| SBC | No single figure. Codec 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 settings the Bluetooth audio standard recommends. | Latency measured by SoundGuys. Bitpool figures from a community write-up summarising the standard, not from the standard itself. | Every Bluetooth audio device has to support it, so it's the fallback everywhere. Its quality setting is agreed per connection, so two pairs of headphones can both "use SBC" and behave nothing alike. |
| AAC | No figure from the makers. Codec 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; codec delay from the same community write-up. Apple publishes nothing. | The Android result was the worst of the four and varied most between phones. There's no comparable published iPhone measurement, so "AAC is fine on an iPhone" is a fair guess, not a sourced fact. |
| aptX | Qualcomm publishes no latency figure on its own aptX page. Codec 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 a reputation borrowed 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 given on that page; 16-bit audio. | Maker's specification (Qualcomm). | Often quoted as 32 ms, but that's the codec's own delay, while Qualcomm's 40 ms is a total figure measured from an adapter. They're different things, so the "disagreement" is mostly people comparing the two. Both ends have to support it, or the connection quietly falls back to something else. |
| aptX Adaptive | "Low system latency approx. 80 ms". | 279–420 kbps, depending on conditions. | Maker's specification (Qualcomm). | Bitrate and latency both change on the fly by design, so the figure is a typical case, not a maximum. |
| LDAC | Sony publishes no latency figure. Codec 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 for sound quality, not speed. The highest-quality mode is the one most likely to need a big buffer. |
| LC3 | No total figure from the Bluetooth SIG. It gives frame intervals of 10 ms and 7.5 ms, which limit the codec's own share of the delay and nothing more. | 160–345 kbps. | Frame interval from the Bluetooth SIG; bitrate range via SoundGuys, quoting the SIG. | LC3 runs on LE Audio, a newer kind of Bluetooth connection, so the measurements above don't apply to it. Independent total figures are still scarce. |
Why the published numbers disagree so much
The pattern in the table is hard to miss. The codec's own delay is a few milliseconds or a few tens, while the delay you feel is several hundred. Almost everything in between is buffering: in your phone or computer's audio system, in its Bluetooth software, and in the headphones themselves, which is the one nobody publishes. The most thorough public breakdown of A2DP says it plainly: total delay depends heavily on the playback device, its chipset and its buffer.
That's why the headphones matter more than the codec name. In the same set of tests, one phone averaged 244 ms across all codecs and another averaged 484 ms, a 240 ms gap with the same headphones on the other end. No codec in the table has a 240 ms gap between its best and worst result. The phone, its chipset and the earbuds' own software change the number more than your choice of codec does.
The other reason is that makers measure on their own hardware. Qualcomm's 40 ms for aptX Low Latency is measured from an adapter running the encoder in a purpose-built Bluetooth device, not your laptop, your Bluetooth software and whatever your earbuds do next. It's a real figure. It just isn't a promise about your setup.
How much delay actually matters
TV broadcasting worked this out long before Bluetooth. ITU-R Recommendation BT.1359-1 reports that for sound and picture, 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 number means the sound is late. People put up with late sound far better than early sound, which is lucky, because late is the only thing Bluetooth does.
Compare the measured figures with that. A 40 ms codec delay is below the point where anyone notices. A 308 ms total delay on SBC is well past the point where the mismatch is merely acceptable. That's why "which codec?" is the wrong first question: good headphones on SBC will beat badly buffered ones on a low-latency codec.
What actually fixes lip-sync
Usually, something already has. Bluetooth added a Delay Report command, which lets your headphones tell your phone or computer how late their sound will be. The video player then holds the picture back to match. That's the whole trick, and it's why a video usually looks fine on the same headphones that ruin a game: the video player can hold frames back until the sound catches up.
A game can't do that. The sound is a response to what you just did, so the delay sits between pressing the button and hearing the result, and holding the picture back would delay your controls too. That's a basic difference, not a setting someone got wrong. If the delay bothers you in games, your options are: use a wired connection, use a transmitter and headphones that both really support a low-latency codec, or use your earbuds' "game mode" if they have one. That almost always means a smaller buffer, at the cost of dropouts when the connection gets busy.
On a TV, look for an A/V sync or audio delay setting and adjust it by hand. On a computer, a USB low-latency Bluetooth adapter usually beats the computer's built-in Bluetooth.
Why no browser test can measure it
No web page can tell you your Bluetooth delay. A page hands the sound to your device's audio system and loses track of it. Browsers do offer an estimate of output delay, but it comes from your operating system and doesn't reliably include what happens after the sound leaves the computer, which on Bluetooth is most of the delay. A page that shows you a number is showing you your operating system's guess, dressed up.
Measuring it properly takes hardware outside the computer. The results quoted above came from a small hardware rig running Google's WALT latency app, with a hundred runs per phone per codec, exactly because software alone can't see its own output.
What we can do is show you whether the connection works and what it's doing to the sound. Our tone generator plays a known pitch you can sweep across the range, which is the quickest way to hear headphones losing the top end or a connection dropping out under load. If it turns out to be your own ears losing the top end rather than the codec, hearing range by age has the published numbers on where that usually sits. If you want to know what the codec is compressing in the first place, sample rate and bit depth explains the raw audio underneath. And if the answer to Bluetooth delay turns out to be a cable, headphone impedance explains whether the wired pair you have in mind needs more than your phone can give it.
Every figure links to its source, and the "where it comes from" column says what kind of source it is. Makers' specifications and independent measurements aren't interchangeable.