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.

 

Comments (10)

  1. 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

    1. 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

  2. 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

  3. 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

  4. 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

    1. 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

  5. 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

    1. 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

  6. 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

    1. 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






Allowed tags: <b><i><br>Add a new comment:


 

Search the newsroom

Latest News & Events

Upping the AI game at the GStreamer Conference 2024

03/10/2024

For the very first time, the GStreamer Conference will be taking place in North America, and we're prepped and ready with no less than 9…

Kernel 6.11: Power moves and hardware grooves

19/09/2024

The latest 6.11 kernel release is here! This release improves performance, security, and hardware compatibility, increasing the kernel's…

PanVK support for Arm V10 GPUs

18/09/2024

It is now possible to start kicking the tires on Vulkan with an open source driver on Arm Mali-G610 and Mali-G310 GPUs. The Panfrost project…

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-2024. All rights reserved. Privacy Notice. Sitemap.