Classic Bluetooth audio had a fundamental problem: every profile was independent. An A2DP headset had no standard way to coordinate with a second earbud. Volume control was handled differently by HFP vs A2DP. Discovering a device’s audio capabilities required proprietary mechanisms.

LE Audio was designed from scratch to fix this. CAP provides:

• Unified discovery — the CAP Acceptor role (identified by CAS) is the single discovery target for all LE Audio sinks and sources
• Standardised procedures — a defined sequence of GATT operations to start, update, and stop audio streams
• Coordinated Set support — native concept of grouped devices (left + right earbud) acting as one logical unit
• Multi-role flexibility — the same device can be an Initiator in one connection and an Acceptor in another

When left and right earbuds are a Coordinated Set (both expose CSIS inside their CAS), the CAP Initiator or Commander treats them as a single logical unit. It can lock the set (prevent other devices from connecting while a stream is active), set the same volume on both, mute both mics at once, and synchronise stream start/stop. This is what makes true stereo TWS headsets possible in LE Audio.

BlueZ added LE Audio / CAP support starting from version 5.62 (experimental) and progressively stabilised it in 5.65+. The CAP Acceptor role (CAS service registration) is available in BlueZ 5.65 onward when using the --experimental flag.

# Check your BlueZ version
bluetoothd --version

# Start BlueZ with experimental features (required for LE Audio)
sudo bluetoothd --experimental

# Or edit /etc/bluetooth/main.conf and set:
# [Policy]
# Experimental = true

# Verify LE Audio feature flags via btmgmt
sudo btmgmt info

A CAP Initiator discovers Acceptors by scanning for devices that advertise the CAS service UUID (0x1853) in their advertisement or expose it as a Primary GATT Service after connection.

# In bluetoothctl, scan for LE devices
bluetoothctl
[bluetooth]# scan le
[NEW] Device AA:BB:CC:DD:EE:FF LE_Audio_Earbuds

# Connect to the device
[bluetooth]# connect AA:BB:CC:DD:EE:FF
[CHG] Device AA:BB:CC:DD:EE:FF Connected: yes

# Switch to GATT menu and list services
[bluetooth]# menu gatt
[bluetooth]# list-attributes AA:BB:CC:DD:EE:FF

# Look for Primary Service: UUID 0x1853 (Common Audio Service)
# If device is a Coordinated Set member, you will also see
# Included Service: UUID 0x1846 (Coordinated Set Identification Service)

In the BlueZ source tree, CAP is implemented in profiles/audio/cap.c. The profile triggers when the remote device exposes the CAS UUID. Below is the pattern used for profile registration:

/* profiles/audio/cap.c — CAP profile registration */

/* CAS UUID is used as the trigger for CAP discovery.
 * When BlueZ sees a remote device exposing CAS (0x1853),
 * it probes the CAP profile. */
#define CAS_UUID    "0000185300001000800000805f9b34fb"

static struct btd_profile cap_profile = {
    .name           = "cap",
    .priority       = BTD_PROFILE_PRIORITY_MEDIUM,

    /* CAP discovery is triggered by finding CAS on the remote device */
    .remote_uuid    = CAS_UUID,

    .device_probe   = cap_probe,    /* Called when CAS is found */
    .device_remove  = cap_remove,   /* Called on disconnect     */

    /* CAP accepts incoming connections from Initiators */
    .accept         = cap_accept,
};

static int cap_probe(struct btd_service *service)
{
    struct btd_device *device = btd_service_get_device(service);

    DBG("CAP Acceptor found: %s", device_get_path(device));

    /* Now read PACS to get audio capabilities,
     * and optionally ASCS to control streams */
    return cap_init(device);
}

/* Register the profile on plugin load */
static int cap_init_plugin(void)
{
    return btd_profile_register(&cap_profile);
}

static void cap_exit_plugin(void)
{
    btd_profile_unregister(&cap_profile);
}