Bluetooth codecs explained: how to choose SBC, AAC, aptX, LDAC or LC3
The codec is the part of a wireless audio product you cannot see, cannot hear in a ten-minute demo, and cannot change after the tooling is cut. What each of the five codecs actually buys you in bitrate, latency and chip licence - and how to specify one without printing a logo you are not entitled to use.
Header photo: Raimond Spekking / Wikimedia Commons, CC BY-SA 4.0
A Bluetooth codec is the compression format that decides how much of the music survives the trip from a phone to an earbud. The classic link carries at most around 1 Mbps of audio payload in good conditions, and raw stereo audio needs several times that, so every codec is a different answer to the same question: what do we throw away? SBC throws away the most and is mandatory in every device. AAC, aptX, LDAC and LC3 each throw away different things at different bitrates, and the one that actually runs is chosen by the phone at connection time - not by your product. That single fact is why two earbuds built on the same chip and the same driver can sound noticeably different to two customers who own different phones.
What the radio link can actually carry
Bluetooth audio for music runs over the A2DP profile on the classic radio. In practice the usable audio payload sits well under 1 Mbps even when the link layer negotiates a higher raw rate, because the payload has to share the air with retransmissions, acknowledgements and any Wi-Fi traffic in the same 2.4 GHz band. That ceiling is the reason the whole codec conversation exists: you are always deciding what to sacrifice.
Two parts of this get missed in most buying conversations. The first is that a codec is not a quality setting you can hand-pick. Both ends advertise a list of codecs they support, and the phone picks the best entry the two lists share. If you want a specific codec to run, you are asking the phone to do something, not asking your earbud to do something. The second is that music and voice are separate pipelines. Music is A2DP; a phone call is HFP, which uses its own codecs - wideband mSBC at 16 kHz sampling when both ends support it, and the old CVSD standard at 8 kHz when they do not. Buyers who test call quality on a product often blame the music codec for a problem that lives in the hands-free profile.
The five codecs your supplier will name
These are the five that appear on datasheets and box copy in almost every wireless audio quotation we see. The bitrate column is the one everybody argues about, and it is the least useful of the five.
| Codec | Typical bitrate | Latency, end to end | Who has to licence it |
|---|---|---|---|
| SBC | 328 kbps stereo at maximum; mandatory baseline | 150-250 ms | Nobody. Free and required on every device |
| AAC | 256 kbps typical | 120-200 ms | Patent pool, but the encoder ships inside the phone OS |
| aptX family | 352 kbps classic, 576 kbps HD, 279-420 kbps Adaptive, up to 1.2 Mbps Lossless | 40-150 ms depending on mode | Qualcomm, on both the transmitter and the receiver |
| LDAC | 330 / 660 / 990 kbps, adaptive | 150-250 ms | Sony; the encoder is built into Android, the decoder is not free |
| LC3 | 16-320 kbps, 160 kbps stereo is the usual working point | 20-50 ms | Royalty free under the Bluetooth LE Audio specification |
Read the table again and notice what it is really telling you. The codecs with the best numbers are the ones with a licence attached to both ends of the link. The codec that is free and fast is the one that requires a newer radio, a newer phone, and a re-test of everything downstream.
SBC: the codec you ship when nobody chose a codec
SBC is a subband codec: it splits the signal into 8 subbands and quantises each one, with block sizes up to 16 samples. It is mandatory in A2DP, so every Bluetooth audio device on the market decodes it, and it is the fallback whenever two devices cannot agree on anything better. On paper it tops out at 328 kbps stereo, which is not embarrassing. In practice, most complaints about SBC are not about the standard at all - they are about implementations.
This is the part suppliers rarely volunteer. SBC has enough room in the spec for a cheap encoder and a good encoder to both be compliant while sounding very different, and the encoder lives in the phone, not in your product. A budget Android handset with a low-effort SBC implementation is the single most common reason a product that sounded acceptable in your meeting room sounds thin in a customer's hands. When a buyer asks us to quote an entry-level product for a market we know is dominated by cheap handsets, we say so plainly: the codec list is SBC and the ceiling is set by the phone, so the money should go into the acoustic design and the fit rather than into a codec logo.
AAC: the codec Apple made good, and Android makes unpredictable
AAC was not designed for Bluetooth; it was designed for streaming, and Apple's implementation of it over the air is the reason the codec has the reputation it has. Apple's encoder is efficient enough that published blind tests have put AAC at 256 kbps ahead of aptX Classic at 352 kbps on identical hardware, and Apple does not support aptX or LDAC at all. That has a hard commercial consequence: if your biggest market is iPhone, AAC is not one option among several, it is the only upgrade path you have, and you do not pay for it.
On Android the same word means something looser. Android devices are licensed to encode AAC, but the implementation differs by chipset vendor, and a poorly tuned encoder can make a product sound worse than it does on SBC. So when a supplier tells you a product "supports AAC", the useful follow-up question is not whether - it is which phone they tested it on, and whether they measured anything.
aptX: a family of four with a licence at both ends
aptX is not one codec. It is a range with different jobs, and quotes that say "aptX supported" without naming the variant are close to meaningless.
- aptX Classic at 352 kbps, 16-bit / 44.1 kHz. The original near-CD claim. Fine, unremarkable, and beaten in blind tests by good AAC.
- aptX HD at 576 kbps, 24-bit / 48 kHz. The version that usually appears on retail box copy.
- aptX Adaptive at 279-420 kbps, adjusting with link conditions. This is the one worth having on a gaming or video product: quoted latencies land in the 50-80 ms band, against 150-250 ms for SBC.
- aptX Lossless, up to 1.2 Mbps and bit-perfect in ideal radio conditions - which is the whole problem, because real rooms are not ideal and the codec falls back to a lossy mode.
All of them require Qualcomm silicon at both the transmitting and the receiving end. That is not a technicality; it is a bill of materials decision. We have watched a European brand commit to an OWS product at 10,000 pcs, choose a cheaper non-Qualcomm SoC to hit a landed cost, and then discover three weeks before artwork sign-off that the aptX HD logo they had planned onto the box was not licensable on that platform. The choices were a per-unit licence on a platform that did not support it, or dropping the claim. They dropped the claim and reprinted the packaging.
LDAC: the 990 kbps claim that needs an empty room
LDAC is Sony's codec and the highest-bitrate option in mainstream Bluetooth, with three working modes: 330, 660 and 990 kbps, up to 24-bit / 96 kHz, and certification under the Japan Audio Society's Hi-Res Audio Wireless mark. The 990 kbps mode is also the clearest example of a specification that is true and misleading at the same time. It needs a clean 2.4 GHz link to hold. In a subway, an airport or a crowded office, the codec steps down - first to 660, then to 330 kbps - and the drop is automatic and invisible to the user.
Two supply-chain facts follow. First, LDAC's encoder is part of Android from version 8 onward, but the decoder in your product is licensed, so "LDAC support" is a line item you should ask to see priced rather than assume. Second, Apple phones do not support it at all, so an LDAC-led product story is an Android-only story, and it is worth checking that your target market is actually Android-heavy before you build marketing around it.
LC3 and LE Audio: the first plumbing change in twenty years
LC3 is the mandatory codec of Bluetooth LE Audio, introduced with the Bluetooth 5.2 core specification in 2020, with the full profile set landing in 2022. It is a different kind of change from the ones above, because it moves audio off the classic radio entirely and onto the low-energy radio that used to carry only small data.
The numbers are worth knowing precisely, because they are the ones you will be quoted. LC3 works from 16 to 320 kbps with frame durations of 7.5 or 10 ms, and its own algorithmic delay is measured in single-digit milliseconds rather than the tens of milliseconds a classic encoder adds. At 160 kbps stereo it is judged roughly equal in quality to SBC at 345 kbps, and at 64 kbps mono it still delivers intelligible speech - a regime where SBC has effectively failed. End-to-end latency for real LE Audio products typically lands in the 20-50 ms band, against 100-200 ms for classic A2DP.
Three structural things come with it, and they matter more to a product plan than the codec itself. Multi-stream audio lets the phone send two synchronised streams, one to each earbud, instead of relaying through the primary bud - which removes a whole class of left-right timing problems on true wireless products. Connected isochronous streams and their broadcast cousins make Auracast possible, so one transmitter can feed an unlimited number of receivers without pairing, which is why airports, gyms and museums are the first serious buyers of this generation. And the hearing aid profile finally puts assistive listening devices inside the standard ecosystem instead of outside it.
On power, one published breakdown puts the reduction in playback current at 20% to 40% depending on the chip platform, which on a small cell is the difference between a playtime claim of 5 hours and one of 8 hours. Treat that as a platform-dependent range, not as a promise, and ask for the measurement.
Codec support is not the same as codec in use
Here is the asymmetry worth carrying into your next supplier meeting. A chip datasheet lists every codec the silicon can decode. That list is a capability, not a configuration. What actually matters is narrower: which codecs are enabled in the firmware you are buying, which of them are licensed per unit, and which ones the phones your customers own will choose to run.
Three consequences follow. A product can support five codecs and run SBC with almost every customer, because that is the only entry the two devices share. A codec can be present and unusable because the firmware build you received has it disabled. And latency numbers quoted from a codec table are not product latency at all: end-to-end delay is the codec plus radio retransmission plus the jitter buffer plus the DSP chain, and the last two are set by the platform and the phone. Every "game mode" claim in this category is a buffer-and-processing reduction, not a codec change, and it is worth asking which phone it was measured on.
The practical version of all this: a demo in your supplier's office proves almost nothing about the codec path. Ask for the phone models, the codec actually negotiated, and the measurement method. If the answer is a spec table rather than a test report, you have been shown marketing.
Six questions to put in the RFQ
These are the questions that separate a codec capability from a codec commitment. Written answers will tell you what the product will really do before you sign, and they cost the supplier nothing but honesty.
- Which codecs are enabled in the shipping firmware, and which of them carry a per-unit licence? Ask for the enabled list, not the supported list, and for the licence terms per codec.
- What is the measured end-to-end latency, on which phone, and how was it measured? A number with a phone model and a method attached is usable. A codec-table figure is not.
- What does the receive side support, and what does the transmitter side support? The two lists are different, and the intersection is what your customer experiences.
- Which chip family is quoted, and what happens to the codec claims if we second-source it? Switching from a licensed platform to a cheaper one usually removes aptX and sometimes removes LDAC - after the packaging is printed.
- Is LE Audio available now, at what bitrate and frame duration, and in which mode? Ask whether the product is dual-mode SBC plus LC3, or LE Audio only, because that decision sets your addressable market.
- How is call audio handled, and can we see a wideband call test? mSBC at 16 kHz against CVSD at 8 kHz is the difference customers describe as "the music is fine but people say I sound far away".
What this means for your product plan
Pick the codec from the market, not from the bitrate table. If your buyers are overwhelmingly on iPhone, AAC is your ceiling and your job is to make sure the acoustic design and the fit are good enough that 256 kbps is not the thing anyone notices. If you are selling to Android flagship owners and the brand story needs a codec name, check the licence line before the artwork, not after. If the product will still be shipping in 2028, design the radio as dual-mode SBC plus LC3 from the start, because that is the direction the phones have already moved and retrofitting costs a whole qualification cycle.
Three things we would refuse to do on a program. We would not print a codec logo on a box without a licence covering the exact chip we are shipping. We would not quote a latency figure that was not measured on a named phone, because latency is the most commonly overstated number in this category. And we would not leave the codec decision until the firmware is frozen, because by then the answer is a new SoC, a new Bluetooth qualification, and a new packaging print run - three costs that together dwarf whatever the codec choice saved. The same logic runs through the technology shifts reshaping earbuds, where LE Audio is one of the changes buyers are being asked to price now.
On a plain SBC product the variant arithmetic stays simple: quoted per model per colour from 1,000 pcs, with each colour a separate line to test and pack. Add a licensed codec and you add a per-unit cost and a firmware configuration to track. Add LE Audio on top of classic and you are maintaining two radio paths through the same qualification - which is exactly why the codec list belongs in the first quotation, next to the driver and the battery, and not in a revision three months later. If the commercial shape of that quotation is unfamiliar, what an MOQ of 1,000 actually includes is worth reading alongside this one.
Sourcing wireless audio with a codec claim you can defend?
Tell us the market, the phone mix and the codec on your box copy. We will tell you which of it is licensable on the platform, what the radio will really negotiate, and which numbers belong in the specification before the tooling is cut.
See our wireless earbuds →