We're hiring!
*

PipeWire: Bluetooth support status update

Frederic Danis avatar

Frederic Danis
April 29, 2022

Share this post:

Reading time:

Over the last two years, Bluetooth® audio support has steadily grown in PipeWire and has become a featureful, stable, conformant, open source Bluetooth® audio stack implementation.

Testimony to that is the fact that, as of last week (April 21), Bluetooth® A2DP audio has been qualified on the Steam Deck using PipeWire and WirePlumber. This means that it is now able to pass the conformance test suite from the Bluetooth SIG and will work against other qualified implementations.

The audio portion of Bluetooth® is split in 2 main categories: one for the stereo and (mostly) uni-directional sound (A2DP profile), and the other for the mono and bi-directional sound (HFP profile). With all the development work that has taken place, here's a look at where things stand.

Stereo audio: A2DP

A2DP stands for Advanced Audio Distribution Profile and it uses the ACL (Asynchronous Connection-Less) channel. It is typically used for the streaming of music content from a stereo music player to headphones or speakers.

The mandatory codec, SBC (SubBand Codec), is a low-complexity, fast, lossy codec that was designed with Bluetooth® bandwidth and processing power limitations in mind. One of its capabilities is that it can dynamically adjust the bitrate. In its default configuration, however, it provides low sound quality.

This can be improved by configuring this codec with better settings, which is proposed by PipeWire as the SBC-XQ configuration, shown in the audio settings of your preferred desktop environment.

In the past few years, though, other codecs with better sound quality have also appeared:

  • AptX (LL, HD): a proprietary codec from Qualcomm (formerly CSR).
  • LDAC: a proprietary codec from Sony.
  • AAC: Advanced Audio Coding (also known as MPEG-2 Part 7).
  • FastStream: a low latency bi-directionnal version of SBC.

As these codecs are not part of the A2DP standard, usage of them greatly depends on the codecs supported by the remote device.

In PipeWire, thanks to its plugin-based architecture, these codecs are supported and are automatically built as plugins when the respective development library is available, i.e.:

  • libsbc for FastStream
  • fdk-aac for AAC
  • libfreeaptx for AptX
  • libldacbt-enc and libldacbt-abr for LDAC

While A2DP officially only supports uni-directional stereo sound, both FastStream and AptX-LL codecs add bi-directional sound capabilities to it, allowing headset microphones to be used in parallel to the stereo stream running to the headphones.

Mono audio and telephony: HFP

HFP stands for Hands-Free Profile and it uses the SCO (Synchronous Connection-Oriented) channel.

This profile is mainly used for communication purposes, enabling headsets and hands-free kits. When used in combination with oFono, PipeWire can also use this profile to communicate with a phone's modem.

Two codecs are available for HFP:

  • The mandatory CVSD for narrow band speech connection, where encoding/decoding is performed in the Bluetooth® chipset.
  • mSBC (Modified SBC) for wide band speech connection, which uses the SBC codec with a specific, fixed configuration. It requires support both from the Linux kernel and the Bluetooth® chipset, which is all automatically detected by PipeWire before making this codec available.

Apart from sound streaming and unlike A2DP, HFP also requires PipeWire to interact with the remote device using AT commands.

The part that enables this interaction can be provided by different backends. There is a native backend for simple interaction with a headset or a phone (where not all AT commands are implemented) and there is also support for using an external daemon like oFono to provide telephony support (i.e. to interact with a modem and make phone calls directly).

The native backend is typically used to provide bi-directional headset audio during meetings/calls on a computer.

What comes next?

Of course, development doesn't stop here. There are still several things to fix and new features to support as the industry moves forward.

One particular feature that we are looking at next, is the addition of the LC3 codec (Low Complexity Communication Codec).

LC3 is the successor of SBC for use in the LE (Low Energy) Audio profile, a new profile that was added in Bluetooth® 5.2. This profile is meant to improve battery life, enable audio broadcasting to multiple devices and also support hearing aids.

Bear in mind, though, that supporting this whole new profile requires work underneath PipeWire, in BlueZ, but until that is ready we can also use LC3 on the A2DP profile and be prepared for LE Audio when the rest of the stack is ready to support it.

 


Add a Comment

 

Search the newsroom

Latest News & Events

Collabora at Embedded World 2026: Open Source AI and Embedded Innovation

05/03/2026

As champions of open source development in the embedded community, Collabora will be at Booth 4-404 with an impressive lineup of live demonstrations…

RK3588 and RK3576 video decoders support merged in the upstream Linux Kernel

25/02/2026

Support for Rockchip’s VDPU381 and VDPU383 decoders is now upstream in Linux, bringing mainline H.264/HEVC decode support, robust IOMMU-reset…

Weston 15.0 is here: Lua shells, Vulkan rendering, and a smoother display stack

19/02/2026

Weston 15.0 has arrived, bringing a brand new Lua-based shell for fully customizable window management, an experimental Vulkan renderer,…

Open Since 2005 logo

Our website only uses a strictly necessary session cookie provided by our CMS system. To find out more please follow this link.

Collabora Limited © 2005-2026. All rights reserved. Privacy Notice. Sitemap.