Early Bluetooth could send voice calls wirelessly (thanks to the Hands-Free Profile), but voice calls use very narrow audio — they sound “telephone-quality.” If you tried to stream music that way, it would sound terrible. A2DP was designed specifically to handle high-quality stereo audio over Bluetooth, giving you CD-quality sound on wireless headphones and speakers.

One important distinction from Hands-Free: A2DP is one-directional only. Audio flows from the source (e.g., your phone) to the sink (e.g., your headphones). There is no return audio path. Hands-Free, on the other hand, is bi-directional because phone calls go both ways.

A2DP depends on two lower-level specifications: GAP (Generic Access Profile) and GAVDP (Generic Audio/Video Distribution Profile). GAP handles discoverability and connection setup; GAVDP provides the general framework for streaming audio or video data.

A2DP defines exactly two roles. Every device in an A2DP connection plays one of them:

• Source (SRC): The device that produces the audio stream. It encodes the raw audio samples and sends them over Bluetooth. Examples: a smartphone, laptop, or media player.
• Sink (SNK): The device that receives the encoded audio, decodes it, and plays it back. Examples: wireless headphones, Bluetooth speaker, or car audio system.

In the diagram above, the mobile phone (SRC) takes raw audio samples from the music app, compresses them with the SBC codec, hands the encoded packets to AVDTP, which transports them over L2CAP and the ACL radio link to the headphone (SNK). The headphone reverses the process — AVDTP receives, SBC decoder decompresses, and the audio plays through the speakers.

The A2DP spec lists these everyday examples to help you understand which device is the SRC and which is the SNK:

Note on point-to-multipoint: A2DP does not natively support sending audio to multiple sinks at once. However, you can achieve this by creating two separate A2DP connections and routing the same audio stream over both connections simultaneously. This is sometimes called “Bluetooth audio broadcasting” in practice.

Raw (uncompressed) audio is enormous. A 48 kHz, 16-bit stereo audio stream needs about 1.5 Mbps of bandwidth. Bluetooth’s ACL link typically provides far less than that for a single connection, so A2DP encodes (compresses) the audio before sending it. On the receiving side, it is decoded back to raw audio. This happens in real time, with very low delay.

A2DP supports several codec options:

SBC (Sub-Band Codec) was specifically designed for the constraints of Bluetooth devices — small memory, low CPU power, and battery-sensitive operation. Here is a simplified explanation of what it does:

1. Sub-band filtering: The audio frequency range (e.g., 20 Hz to 20 kHz) is split into 4 or 8 frequency bands using a filter bank.
2. Quantisation: Each band’s samples are quantised (rounded) with a number of bits proportional to how important that frequency range is to human hearing.
3. Bit allocation: More bits are given to frequency bands that carry more perceptible information, and fewer bits to ranges humans barely notice.
4. Framing: The quantised values are packed into SBC frames and handed to AVDTP for transmission.

The result is a stream that is typically 3–5× smaller than the original PCM audio, at quality that is very close to CD audio for casual listening.

BlueZ SBC configuration structure (from the BlueZ source):

/* From BlueZ sbc/sbc.h — SBC codec configuration */
typedef struct {
    uint8_t frequency;      /* Sampling frequency: 16000, 32000, 44100, 48000 Hz */
    uint8_t blocks;         /* Number of blocks: 4, 8, 12, or 16 */
    uint8_t subbands;       /* Number of sub-bands: 4 or 8 */
    uint8_t mode;           /* Channel mode: MONO, DUAL_CHANNEL, STEREO, JOINT_STEREO */
    uint8_t allocation;     /* Bit allocation: LOUDNESS or SNR */
    uint8_t min_bitpool;    /* Minimum bitpool value (controls quality) */
    uint8_t max_bitpool;    /* Maximum bitpool value */
} sbc_t;

A higher max_bitpool value means higher quality but more bandwidth. A typical stereo stream at 44.1 kHz uses a bitpool of around 53, giving roughly 328 kbps.

Imagine you are listening to music on your phone via Bluetooth headphones while jogging. Your phone is in your pocket. You want to skip to the next track — but you do not want to pull your phone out. AVRCP is exactly the profile that allows your headphone to send a “next track” command to your phone, and your phone to respond by changing the song.

AVRCP standardises how control commands (play, pause, stop, volume up, next track, etc.) are exchanged between Bluetooth devices. Think of it as the Bluetooth version of a TV remote control.

AVRCP depends only on GAP (Generic Access Profile). Unlike A2DP which uses AVDTP for data transport, AVRCP uses AVCTP (Audio/Video Control Transport Protocol) to carry its commands.

Just like A2DP, AVRCP defines two roles for every connection:

• Controller (CT): The device that initiates a command. It decides what action to request. Example: a Bluetooth headphone pressing the “pause” button sends a command to the phone.
• Target (TG): The device that receives the command, executes it, and sends back a response (success or failure). Example: the phone receives “pause” and pauses the music player.

Notice the two-way arrows in the middle — AVRCP is a request–response protocol. The controller sends a command and the target sends back a confirmation. This way the controller knows whether its request was actually carried out.

AVRCP covers a wide range of control operations. Not every device has to support all of them — a simple headphone button might only implement play/pause, while a full home-theatre controller could support all of the following:

The “Unit/Subunit Info” command is interesting — it lets one device ask another device what type it is (e.g., Player/Recorder, Monitor/Amplifier, Tuner) and what sub-units it contains. This allows auto-discovery of capabilities, similar to how SDP (Service Discovery Protocol) works at the Bluetooth level.

AVRCP does not invent its own command language from scratch. Instead, it borrows the AV/C command set from the IEEE 1394 (FireWire) trade association specification. This is a great example of how Bluetooth reuses existing, proven industry standards instead of reinventing the wheel.

The AV/C (Audio/Video Control) command set defines a structured way to send commands to audio and video equipment. Commands are organised by “unit” and “subunit” type — you first identify what kind of device you’re talking to, then you send the appropriate command for that device type. This makes AVRCP work cleanly across a very wide variety of device types.

In nearly every real Bluetooth audio product, A2DP and AVRCP are deployed together as a pair. A2DP handles the audio stream; AVRCP handles the control commands. Here is how they interact in a typical “headphone + phone” scenario:

The A2DP stream runs continuously. When the user presses next track on the headphone, AVRCP sends the command over a completely separate logical channel (AVCTP, not AVDTP). The phone processes it, switches tracks, and the new audio automatically flows back through the existing A2DP stream. The two profiles are independent but complementary.