What You Will Learn
Before writing a single line of LE Audio code, you need to understand why it was invented. Engineers who skip this foundation end up confused about why LE Audio works the way it does.
- How A2DP and HFP work at the protocol level — stacks, transports, codecs
- Why ACL and SCO links are fundamentally different and why that matters
- The AVDTP codec negotiation flow before music starts playing
- How TWS earbuds work today using proprietary relay and sniffing schemes
- Why this proprietary ecosystem is an engineering and business problem
Classic Bluetooth Audio — Two Profiles, Two Worlds
Every piece of audio you have ever heard through a Bluetooth device used one of exactly two profiles: A2DP for music and HFP for calls. They were designed independently, work completely differently, and share almost nothing at the protocol level. That design decision is the root of many problems LE Audio was built to solve.
| Property | A2DP — Advanced Audio Distribution | HFP — Hands-Free Profile |
|---|---|---|
| Primary Use | Music, podcasts, video audio | Phone calls, voice assistants |
| Direction | One-way only (source → sink) | Bidirectional (phone ↔ headset) |
| Audio Quality | High — stereo, up to 320 kbps | Low — mono, 8 kHz NB or 16 kHz WB |
| Mandatory Codec | SBC (optional: AptX, AAC, LDAC) | CVSD (NB) / mSBC (WB, HFP 1.6+) |
| Transport Layer | ACL link via AVDTP over L2CAP | SCO / eSCO link (dedicated audio slot) |
| Retransmission | Yes — ACL is reliable | No — SCO drops lost packets |
| Typical Latency | 100–200 ms | 30–60 ms |
| Topology | 1 source → 1 sink only | 1 phone ↔ 1 headset only |
| Introduced | 2006 | 2003 |
A2DP — How Music Streaming Works at Protocol Level
A2DP sits on top of AVDTP (Audio Video Distribution Transport Protocol). AVDTP has two jobs: negotiate how the audio stream is set up, then carry the compressed audio data. Here is the complete stack:
| Audio Application Spotify, YouTube, Music Player |
| ↕ |
| A2DP Profile Compresses audio → SBC / AptX / AAC frames |
| ↕ |
| AVDTP — Audio/Video Distribution Transport Protocol Stream endpoint discovery + codec negotiation + media transport |
| ↕ |
| L2CAP — Logical Link Control and Adaptation Protocol |
| ↕ |
| ACL Link — Asynchronous Connection-Less Retransmitting, best-effort delivery over BR/EDR baseband |
| ↕ |
| Bluetooth BR/EDR Radio — 2.4 GHz |
The AVDTP Codec Negotiation — Before Any Music Plays
Before audio flows, AVDTP runs a signalling exchange to discover what the sink supports and agree on a codec. This is called the stream setup phase. The phone always drives it.
| Phone (A2DP Source) | AVDTP Message | Headphones (A2DP Sink) |
|---|---|---|
| Discover stream endpoints → | AVDTP Discover | |
| Discover RSP | ← SEP ID=1 type=SINK codec=SBC | |
| What codecs do you support? → | Get Capabilities | |
| Capabilities RSP | ← SBC {bitpool 2-53}, AAC, AptX | |
| Phone selects best common codec (e.g. AptX if available, else SBC) | ||
| Use SBC, bitpool=53, stereo → | Set Configuration | |
| Set Config RSP | ← Accepted | |
| Open stream → | Open / Start Stream | ← Accepted / Started |
| ═══════ SBC / AptX encoded audio frames flowing continuously ═══════ | ||
SEP = Stream End Point — a logical audio source or sink endpoint defined in AVDTP
SBC Frame Structure Inside an A2DP Packet
| A2DP Media Packet | ||||
| RTP Header 12 bytes seq + timestamp |
SBC Header 4 bytes |
SBC Frame 1 encoded audio samples 4 sub-bands, 8 blocks |
SBC Frame 2 … N multiple frames per packet |
Padding |
HFP — Two Parallel Channels Run Simultaneously
HFP runs two completely separate channels at the same time: a control channel for AT command call management and a dedicated SCO audio link for the voice data itself.
| Phone Call Handler / Voice Application | ||
| Control Channel AT commands — call control, volume, mute |
‖ | Audio Channel Voice PCM — bidirectional |
| ↕ | ↕ | |
| RFCOMM → L2CAP → ACL Reliable, retransmitting |
SCO / eSCO Link Fixed time-slot, no retransmission CVSD (NB) or mSBC (WB) |
|
| ↕ | ||
| Bluetooth BR/EDR Radio — 2.4 GHz | ||
HFP AT Command Exchange — What Travels on the Control Channel
| Phone → Headset | Direction | Purpose |
|---|---|---|
| AT+BRSF=… | → | Feature negotiation |
| AT+CIND=? | → | Query call status indicators |
| RING | ← | Incoming call notification |
| AT+VGS=12 | → | Set speaker volume to 12 |
| AT+ATA | → | Answer the call |
| AT+CHUP | → | Hang up the call |
| WB-Speech (mSBC) codec negotiation — HFP 1.6+ | ||
| AT+BCS=2 | → | Phone proposes codec ID 2 (mSBC) |
| +BCS: 2 | ← | Headset accepts mSBC → SCO opened at 16 kHz |
ACL vs SCO — Why Two Different Link Types Exist
The Bluetooth baseband has two fundamentally different link types. Understanding the difference explains why HFP and A2DP cannot share a transport.
| ACL Link — Used by A2DP | SCO Link — Used by HFP | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
||||||||||||||||||||
The Core Problem: Strict Point-to-Point Topology
Both A2DP and HFP hard-code a single connection between exactly two devices. One phone, one headset. One source, one sink. No exceptions. This was fine in 2006, but the world moved on.
| Status | Use Case | Reason |
|---|---|---|
| ✅ | Phone → Headphones (music) | 1 source, 1 sink — spec supports this |
| ✅ | Phone ↔ Car Kit (call) | 1 phone, 1 headset — spec supports this |
| ❌ | Phone → Left Earbud + Right Earbud | Spec only allows 1 sink — no standard multi-sink |
| ❌ | Phone → Earbuds + Bluetooth Speaker | Only one A2DP connection permitted at a time |
| ❌ | TV → Multiple headphones simultaneously | A2DP is strictly one-to-one |
| ❌ | Stage → Audience hearing aids (broadcast) | No broadcast audio mechanism exists in classic BT |
| ❌ | Seamless voice ↔ music switch | Requires full HFP → A2DP profile switch, audio gap |
True Wireless Stereo (TWS) — The Proprietary Workaround
Stereo earbuds look seamless from the outside, but TWS is not a Bluetooth standard feature. Every product uses a proprietary chip vendor extension. There are two main engineering approaches.
Approach 1 — The Relay (Forwarding) Method
|
📱 Phone
A2DP Source |
||
|
A2DP Stereo Stream (SBC)
↓
|
||
|
🎧 PRIMARY Earbud (Right)
1. Receives full stereo A2DP stream
2. Decodes LEFT + RIGHT channels 3. Keeps RIGHT channel for itself 4. Forwards LEFT channel ➜ secondary 5. Delays RIGHT playback to sync |
||
|
LEFT channel
←
via BT 2.4GHz
or NFMI link |
||
|
🎧 SECONDARY Earbud (Left)
Receives relayed LEFT channel
Plays when primary signals ready |
Plays RIGHT channel
Delayed to match secondary’s
playback time |
| Stage | What Happens | Added Latency |
|---|---|---|
| A2DP encode | Phone compresses + buffers audio | ~100 ms |
| A2DP transmit | Phone → Primary earbud | ~20–40 ms |
| Relay transmit | Primary → Secondary earbud | ~10–30 ms extra |
| Sync delay | Primary waits to match secondary | = relay transmit time |
| Total | End-to-end audio latency | ~150–200 ms — too high for gaming/video |
Approach 2 — The Sniffing Method
|
📱 Phone
A2DP Source |
||||||
|
A2DP stream
↙
|
A2DP stream
↘
|
|||||
|
🎧 SECONDARY (Left)
Silent listener
No ACK sent to phone Receives decryption key +timing from primary Decodes LEFT channel |
← side-channel →
timing + key |
🎧 PRIMARY (Right)
Sends ACK to phone
Decodes RIGHT channel Sends timing key to secondary over side link |
||||
|
||||||
The Ecosystem Fragmentation Problem
| Vendor | TWS Solution | Works With | Mix Different Brands? |
|---|---|---|---|
| Apple | Proprietary W1/H1 chipset | Apple products only | No |
| Qualcomm | TrueWireless (from CSR) | Qualcomm chipsets only | No |
| MediaTek / Others | Vendor-specific variants | Same vendor only | No |
| LE Audio (Standard) | CIG/CIS — Bluetooth 5.2 spec | Any LE Audio device | Yes |
Key Takeaways — Part 1
Part 2: Bluetooth LE Audio — The Solution
Part 2 covers exactly how LE Audio solves all of this — ISO channels (CIS and BIS), the LC3 codec, multi-stream topology, broadcast audio, and real BlueZ ISO socket code.