April 29, 2022
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.
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:
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.:
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.
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:
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.
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.
Less than a day away, May 18th looks to be a very busy time. With Live Embedded Event and Embedded Vision Summit taking place almost simultaneously,…
Over the last two years, Bluetooth® audio support has steadily grown in PipeWire and has become a featureful, stable, conformant, open source…
Looking to use hardware-backed and virtual SocketCAN interfaces inside your Kubernetes Pods? A new device plugin now allows processes inside…