Bluetooth® audio has come a long way since 2001, when the Headset Profile (HSP) and Hands-Free Profile (HFP) first enabled bidirectional voice calls over Synchronous Connection-Oriented transport. The Advanced Audio Distribution Profile (A2DP) followed in 2003, bringing high-quality audio streaming to our headphones and speakers. While these Bluetooth® "classic" profiles have served us well for over two decades, they come with fundamental limitations that have become increasingly apparent in modern use cases.

If you've ever wondered why your music quality drops dramatically when you answer a call on your Bluetooth® headset, you've experienced one of A2DP's key limitations firsthand. Its unidirectional nature means that enabling a microphone requires switching to HFP, resulting in that noticeably reduced audio quality. Beyond this, Bluetooth® classic exhibits high latency (100-200ms for A2DP) and high power consumption, by modern standards, which results in inadequate battery life for all-day use cases like hearing aids. These and many more limitations have led vendors over the years to drive this outdated technology to its limits and develop non-standard solutions such as Google's Audio Streaming for Hearing Aids (ASHA) profile and Apple's Made for iPhone (MFi) extensions.

Enter LE Audio, introduced with Bluetooth® 5.2 in 2020, which represents a fundamental shift in the Bluetooth® audio architecture. This post outlines what changes LE Audio brings, what its support status is on Linux, and what lies ahead for building great Linux-based products that make use of this functionality. The content of this post was originally a talk presented at the Embedded Linux Conference Europe 2025, which you can watch here.

What is LE Audio?

LE Audio is built on the Bluetooth® Low Energy (LE) stack rather than the Basic Rate / Enhanced Data Rate (BR/EDR) stack used by classic Bluetooth®. This isn't just a minor technical detail. Bluetooth® Low Energy is an entirely separate wireless communication stack from Bluetooth® BR/EDR, comparable to the difference between Wi-Fi and Bluetooth® themselves. This new foundation achieves significantly lower power consumption and latency, enabling use cases that were previously impractical or impossible.

Unlike Bluetooth® classic's approach of defining separate profiles for different scenarios, LE Audio provides a modular framework of profiles working together. At its core is the Basic Audio Profile (BAP), which defines audio transport for all use cases. Built on top of this are supporting profiles: the Volume Control Profile (VCP), Microphone Control Profile (MICP), Coordinated Set Identification Profile (CSIP - for devices "sets", like earbuds), Call Control Profile (CCP - replacing HFP functionality), and Media Control Profile (MCP - replacing AVRCP). Higher-level profiles like the Telephony and Media Audio Profile (TMAP), Hearing Access Profile (HAP), and Public Broadcast Profile (PBP) then define specific use cases built on these foundations. And at the codec level, it is all powered by the newly developed Low Complexity Communication Codec (LC3).

Image source: https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/le-audio/le-audio-specifications/

Auracast™: Broadcasting audio to multiple devices

One of LE Audio's most significant innovations is Auracast™, enabled through the Public Broadcast Profile. Auracast™ allows audio to be broadcast to multiple receivers simultaneously, almost like traditional analog radio, but with all the benefits of a secure digital wireless connection. The applications are compelling: assistive listening in public venues like theaters or conference halls, access to audio sources like TVs in public spaces, or silent movie nights with friends in your living room.

Auracast™ sources work similarly to Wi-Fi access points where users can use a QR code or scan the area to find and connect to the source of their choice. Transport is handled through Isochronous Streams, which provide synchronized delivery essential for coordinating multiple receivers.

LE Audio on Linux: BlueZ and PipeWire

On Linux, LE Audio support is implemented through BlueZ for the Bluetooth® host stack and PipeWire for audio routing. PipeWire has outstanding Bluetooth® support, implementing all major profiles including A2DP with multiple codecs, HSP/HFP in both gateway and hands-free roles, the ASHA hearing aid protocol, and now LE Audio.

For LE Audio specifically, PipeWire supports BAP in all roles (unicast sink/source and broadcast sink/source), handles the Volume Control Profile in coordination with BlueZ, and manages coordinated device sets by presenting earbuds as a single logical device while routing audio to both physical devices.

Hardware and Software Requirements

Getting LE Audio operational on your Linux system requires careful attention to both hardware and software components. You'll need Linux kernel 6.4 or later, though we strongly recommend using later versions due to ongoing fixes. Fairly recent versions of BlueZ and PipeWire are also essential.

On the hardware side, controller support varies. Many vendors, such as Intel, NXP, Mediatek, Qualcomm, Nordic, and others implement LE Audio support in their recent models. However, Auracast™ support is not always a given. For instance, Intel supports LE Audio in both their AX110 and BE200 series, but only BE200 supports Auracast™.

You can verify your controller's capabilities using bluetoothctl's management menu (menu mgmt). Look for cis-central cis-peripheral for unicast support, and iso-broadcaster sync-receiver for broadcast support.

Configuration and Setup

Configuring LE Audio requires enabling experimental features in BlueZ's /etc/bluetooth/main.conf, including the ISO socket UUID in the kernel experimental options. The ISO socket is a Linux kernel feature currently marked experimental but nearing stable status, so expect this requirement to become simpler in future releases.

Experimental = true
KernelExperimental = ...,<ISO socket UUID>

In PipeWire, WirePlumber will enable LE Audio support by default unless you have custom Bluetooth® configuration, in which case you should refer to the documentation of the bluez.roles option.

After configuration, running the show command in bluetoothctl should display "Published Audio Capabilities" for LE Audio and "Broadcast Audio Scan" for Auracast™, confirming that everything is properly set up.

Similarly, after connecting to a remote Bluetooth® device that supports LE Audio, you should be able to see the same listings when running the info command in bluetoothctl, along with listings of other LE Audio profiles. Remember that the info command displays the capabilities of the connected remote device, while the show command displays the capabilities of the local controller.

The Dual Stack Challenge

One significant challenge that you'll need to be aware of involves dual stack devices that support both Bluetooth® classic and LE Audio. Since these are separate stacks, switching between them currently requires disconnecting the device and re-connecting it with the other stack configured as "preferred". This is fundamentally different from the classic A2DP vs HFP profile selection, which can be done on the fly without disconnecting.

Currently, the bearer command in bluetoothctl allows specifying le or bredr mode as preferred. BlueZ 5.84 will introduce improved tooling with explicit stack connection status and a D-Bus API for programmatic control. However, the user experience challenge of stack switching and per-stack pairing remains an active area of development.

The Road Ahead

There is still significant work ahead for LE Audio in the BlueZ ecosystem. Contributors are actively engaged in improving usability through both command-line and GUI tools, including desktop integration. Things like Auracast™ controls for browsing and connecting to broadcast sources, as well as controls for switching between LE Audio and classic, are on the high priority list.

We're also working on creating a unified call control API that serves both LE Audio's Call Control Profile and classic Bluetooth®'s HFP. This involves also moving parts of the HFP implementation from PipeWire into BlueZ, which will eventually deprecate the "telephony" support in PipeWire that was introduced earlier this year.

In addition, to ensure that everything works up to spec, the BlueZ + PipeWire stack needs to undergo official qualification testing and get approval from the Bluetooth® Special Interest Group (SIG). This is a substantial amount of work that we aim to have under control within 2026.

Finally, the modular nature of LE Audio means the Bluetooth® SIG continues developing new features that will require ongoing implementation work in the Linux stack.

We can help!

LE Audio and Auracast™ represent a substantial advancement in wireless audio capabilities for Linux systems. While the technology is still maturing and some rough edges remain, the foundation is solid and actively developed. The implementation spans multiple components from kernel drivers through BlueZ and PipeWire to user-facing applications, requiring careful coordination across projects. Thankfully, it is embraced by an amazing community of people who are in active communication and collaboration with each other, dedicated to making this the best LE Audio implementation out there.

If you're considering deploying LE Audio on your embedded Linux system, our team has hands-on experience with this entire software stack and can assist at every step, from evaluating hardware compatibility and configuring BlueZ and PipeWire to implementing custom patches and ensuring your system meets qualification requirements. We're also active contributors to both BlueZ and PipeWire, giving us insight into the roadmap and ongoing developments. Get in touch with us to learn more!