products

Technical Sharing

Home>Technical Support>Technical SharingA2DP and AVRCP: Bluetooth Audio Streaming and Control Protocols

A2DP and AVRCP: Bluetooth Audio Streaming and Control Protocols

Published: 2026-08-25  |  Author: Liwei Electronics

A2DP and AVRCP at a Glance

A2DP (Advanced Audio Distribution Profile) defines a one-way, point-to-point streaming path for stereo audio from a Source device (phone, PC, media player) to a Sink device (headset, speaker, car head unit). The profile mandates SBC as the baseline codec and lists AAC, aptX, LDAC, and LC3 as optional codecs that may be negotiated if both ends support them. AVDTP (Audio/Video Distribution Transport Protocol) sits directly beneath A2DP and handles packet framing, codec capability exchange, and the SET_CONFIGURATION step that finalises the chosen codec. A2DP does not specify how the audio is compressed, it only specifies how the compressed bitstream is transported.

AVRCP (Audio/Video Remote Control Profile) does the opposite job. It defines a control channel that lets the headset forward user gestures (play, pause, next track, previous track, volume up/down) back to the Source device. Underneath AVRCP sits AVCTP (Audio/Video Control Transport Protocol), which fragments commands into transport-sized packets. AVRCP works in two roles: CT (Controller) is typically the headset and TG (Target) is typically the phone.

Protocol Stack and Command Set

The full A2DP/AVRCP stack from the bottom up is: RF physical layer (BR/EDR) → Baseband/LMP → L2CAP → AVDTP/AVCTP → A2DP/AVRCP application layer. AVDTP negotiates codec capability and configures the stream; A2DP manages the streaming session.

AVRCP versions matter for end-user features. 1.3 adds metadata (track title, artist, duration). 1.4 adds browsing (file system navigation). 1.6 standardises absolute volume and battery status feedback. Common AVRCP opcodes include PLAY (0x44), PAUSE (0x46), STOP (0x45), FORWARD (0x4B), BACKWARD (0x4C), VOLUME_UP/DOWN (0x41/0x42), and metadata requests (0x70/0x71).

When a user presses "next track" on the headset, the path is: button press interrupt → AVCTP packet → L2CAP channel → phone AVRCP TG parser → media player action. Round-trip latency in a clean RF environment is roughly 30 to 80 ms, which is why headset remote buttons feel near-instant.

Codec Negotiation and B-End Selection

A2DP only covers transport, not compression. SBC is mandatory. AAC, aptX, aptX HD, LDAC, and LC3 are optional and require both Source and Sink SoCs to support them. The codec is finalised during AVDTP SET_CONFIGURATION. The Source side (phone OS) drives the selection: iOS prefers AAC, Android varies by vendor (aptX, LDAC, or SBC fallback). If your headset advertises AAC support but the phone does not, the link will fall back to SBC.

For B-end product teams, A2DP and AVRCP are mostly handled by the SoC SDK. Real engineering work concentrates on three areas: SoC capability (which AVRCP version and which A2DP codecs are supported; whether absolute volume and multipoint work), button event mapping (physical button press to AVRCP command, including double-click, long-press debounce, and volume/media key priority), and cross-platform compatibility testing (verify codec negotiation, metadata display, and absolute volume on iOS, Android, Windows, macOS).

Liwei Electronics preloads AVRCP 1.6 and full A2DP codec negotiation in its Bluetooth headset reference designs (music headsets, TWS, K-song headsets), and ships a button mapping reference implementation so customers can move from prototype to mass production quickly.

FAQ

Q: Can A2DP and AVRCP work independently?

A: No. A2DP carries the audio downstream, AVRCP carries the control upstream, both must be established together to support a full "listen and control" experience. Some car head units only enable HFP (voice call) and skip A2DP/AVRCP, which is why phone media playback produces no output on those systems.

Q: Is a higher AVRCP version always better?

A: Not necessarily. The browsing and metadata features added in AVRCP 1.4 and 1.6 only show up if the host app parses and displays them. If the media app ignores AVRCP metadata, the user-visible gap between 1.3 and 1.6 is minimal. Choose based on what your target OS and apps actually support.

Q: Why does the same headset negotiate different codecs on different phones?

A: A2DP codec negotiation is driven by the Source side policy. iOS tends to pick AAC, Android may pick aptX, LDAC, or fall back to SBC depending on the vendor implementation. The final codec depends on the phone OS and its Bluetooth stack, not just the headset.

Key Technical Takeaways

  • A2DP负责音频下行,AVRCP负责反向控制,两者协同支撑蓝牙音乐
  • 协议栈:射频→L2CAP→AVDTP/AVCTP→A2DP/AVRCP
  • A2DP强制SBC,其他编解码器由收发两端SoC协商
  • B端选型关注AVRCP版本、按键映射、跨平台兼容性

About Liwei Electronics

深圳市力为电子专注音频耳机方案设计,覆盖蓝牙音乐耳机、TWS、K歌耳机等产品线,欢迎联系。

Keywords: A2DP, AVRCP, Bluetooth audio profile, AVDTP, SBC codec

Free development and design
Customized exclusive solution PCBA design
top