Frederic Danis
April 29, 2022
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.
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.
15/11/2024
The Linux Foundation Member Summit is an opportune time to gather on the state of open source. Our talk will address the concerns and challenges…
14/11/2024
Today, we are delighted to announce a growing collaboration with MediaTek which will enable Collabora to introduce, improve, and maintain…
06/11/2024
Join us at electronica 2024! In partnership with Renesas, Collabora will be showcasing GStreamer open source AI video analytics on the Renesas…
Comments (10)
Zoli:
Apr 29, 2022 at 07:05 PM
Isn't LC3 gimped by licencing? IIRC its main improvement over Opus was making profit for Fraunhofer on everyone implementing LE audio
Reply to this comment
Reply to this comment
Will:
Apr 30, 2022 at 08:53 AM
Cynicism noted, and largely agree.
Opus is still great but it's not designed for use in a wireless environment where signal quality can vary greatly. In short, it doesn't degrade well. Also it's still a bit expensive, in terms of computation time and transistors, to decode.
Reply to this comment
Reply to this comment
Mitchel:
Apr 30, 2022 at 12:17 AM
Great work. can't wait to see LC3 as I hear it has quite low latency. so I myself am particularly excited for it. However I have a question, How feasible would it be to implement opus as an a2dp profile? I realize that it wouldn't get much use as no devices support it.
however since linux can be used as both a source and a sink, I think it would be really cool for hobbyist projects. opus has good encoders and decoders available, and has a very clear open licensing.
I think it could be really cool as an a2dp codec and quite beneficial, even if unofficially.
Reply to this comment
Reply to this comment
Paulo:
May 01, 2022 at 12:11 PM
i want my bluetooth headset to work properly on linux, even the ones made in china! it's stressful trying to get it to work when you have pulseaudio, pipewire and phonon simultaneously on the plasma interface, for example.
Reply to this comment
Reply to this comment
Be:
May 01, 2022 at 07:39 PM
Do the telephony features require oPhono? That seems like a strange choice considering Phosh and Plasma Mobile are both using ModemManager now.
Reply to this comment
Reply to this comment
Frédéric Danis:
May 10, 2022 at 10:17 AM
Currently only oFono provides the bridge between HFP AT commands and the modem.
The PipeWire native HFP supports a minimal set of AT commands to be able to setup the connection. This support maybe increase when ModemManager is available.
Reply to this comment
Reply to this comment
Mitchel Stewart:
May 01, 2022 at 08:52 PM
Great work, quite excited to the latency improvements of LC3. however I was wondering, would it be possible to use opus as an a2dp codec? I understand it wouldn't get much use in consumer electronics, however for hobbyists I think it could be really cool since you can use linux as both a source and a sink. opus seems like it would be a really good codec for a2dp audio.
Reply to this comment
Reply to this comment
Frédéric Danis:
May 10, 2022 at 10:06 AM
It should be possible to add a PipeWire SPA codec library for Opus like for the other codecs, but it will also need do define specific vendor and codec IDs for A2DP to be able to select it.
You should open an enhancement issue to discuss this on https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
Reply to this comment
Reply to this comment
Cryio:
Jun 24, 2022 at 12:43 PM
Any chance of Pipewire supporting the LHDC codec as well? Or anything have an idea of where should I look to getting this codec working on Fedora? Is it even available?
Reply to this comment
Reply to this comment
Frédéric Danis:
Jun 27, 2022 at 07:44 PM
This is not currently supported by PipeWire, and afaik there's no open-source library implementing the LHDC codec.
You may add a request for in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
Reply to this comment
Reply to this comment
Add a Comment