We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Bluetooth state in PipeWire and WirePlumber

00:00

Formal Metadata

Title
Bluetooth state in PipeWire and WirePlumber
Title of Series
Number of Parts
542
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Over the last two years, Bluetooth® support has seen significant improvements in PipeWire and WirePlumber. In this talk, we'll take a closer look at these changes, including the recently added initial support for next generation Bluetooth LE Audio, and discuss future plans. This talk targets everyone who cares about Bluetooth Audio support in Linux, not only for the Linux desktop but also for embedded Linux projects.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
StatisticsSoftware engineeringSoftware testingPower (physics)Computer animation
Food energyUser profileDistribution (mathematics)FreewareDisk read-and-write headVideoconferencingProfil (magazine)Pulse (signal processing)Streaming mediaDistribution (mathematics)Classical physicsEinbettung <Mathematik>Category of beingLink (knot theory)Physical systemComputer animation
Streaming mediaLibrary (computing)ModemCodierung <Programmierung>Computer hardwareClassical physicsSet (mathematics)MultilaterationCodecTelecommunicationEvoluteOpen setRevision controlHypermediaCodierung <Programmierung>Sound cardFront and back endsKernel (computing)Connected spaceModemMobile WebComplete metric spaceDistribution (mathematics)Streaming mediaProfil (magazine)Cartesian coordinate systemLink (knot theory)Run time (program lifecycle phase)Network socketStructural loadComputer hardwareConfiguration spaceLatent heatMiniDiscCodeFamilyFunction (mathematics)Remote procedure callLimit setComputer animation
CodeStreaming mediaMultiplicationAsynchronous Transfer ModeGeneric programmingHypermediaBroadcasting (networking)Kernel (computing)Latent heatProfil (magazine)Interactive televisionKernel (computing)CodecTransmissionskoeffizientBroadcasting (networking)Software testingLevel (video gaming)Configuration spaceComputer animation
Computer animation
Program flowchart
Transcript: English(auto-generated)
OK, we are starting. Hello, I'm Frederic Dennis, software engineer at Colaboa, and I will present you the Bluetooth test in wire plumber and power wire and wire plumber. Pipe wire is a low-latency graph-based processing engine that tends to handle the audio and video streams.
It is intended to replace both pulse audio and jack audio systems. Wire plumber is in charge of creating the audio and video
nodes and the link between the nodes according to the policies defined by the system or the users. Both of them are designed for desktop. Main distributions are switching to them or to the embedded.
More specifically, for Bluetooth, the Bluetooth classic audio profiles are divided in two main categories. The mono, the stereo, and mostly unidirectional audio streaming called A2DP. And the mono and bidirectional profiles,
which is industry profile and headset profile, the latter less and less used. So for the Bluetooth classic audio profiles, A2DP stands for Advanced Audio Distribution Profiles.
It aims to manage audio streaming between media player and headset speakers. And in this table, you can see the supported codecs. The first one is SBC codec, which
is low complexity, fast, and lossy, but is implemented on all devices. The A2DP specification allows other codecs, like AEC, which is optional and not implemented on all device.
And the specification allows also other codecs not defining the specification. Most of them have been implemented to improve the audio quality, but are not supported by all devices. For example, the APTX family of codecs
can be found on Qualcomm devices or need licensing from Qualcomm, or the LDAC codec is found on Sony devices. In PyPwire, we use this ability to add some other codecs, like Opus, which is an open format,
or L3Pus, which is an enhanced version of the codec used in LED audio, which we'll talk later. And some founders have the ability to do bidirectional audio on A2DP with the fast stream codec, which
is an evolution of the SBC codec, or the APTX lossless codec, which is one of the APTX family. Just what I was saying, last year, we were able to pass the Bluetooth qualification using both PyPwire and wire popular on the Steam Deck.
HFP stands for hands-free profile. It is used for communication usage. But unlike the A2DP-1, it also defines the commands to interact with the telephony using a set of AT commands.
This can be done with external daemons, like HSP, HFPD, or Ofono, Ofono adding a complete support for the modem, or with the native back end, which is only a limited set of AT commands allowing to complete the connection with Bluetooth
devices. Yes. And this can be used with configurating application. Last year, we added to the native back end the support for modem manager, allowing to have a complete telephony usage from inside the Bluetooth
from inside PyPwire, sorry. So with Ofono, our modem manager, PyPwire adds a complete telephony support to the mobile distribution device, mobile device distribution.
HFP supports two codecs, the mandatory one, which is CVSD, which is a narrowband audio connection. In this case, in this case, yes, for the CVSD,
the audio is sent directly to the Bluetooth chipset, which will anchor the data through the blue disk or socket. And the second codec is MSBC, which is optional. It's a fixed set, a fixed configuration of SBC.
But it needs both support from kernel and the chipset. And it is automatically detected during runtime by PyPwire. But on some hardware devices, the chipset
has a direct audio link connected to an audio card or to the modem. To be able to support it, we add a hardware scope of load mode, which allows PyPwire to only use this code socket to create and connect to the remote,
to connect and configure the remote, the link to the remote device. While wire pamper will create a pass-through node, allowing the user to select the Bluetooth remote device as an audio output. And then the data are sent to the audio card, which
plays them to the Bluetooth chipset, which will at the end encode and send the data over the air. Now, we'll do a quick overview of the new low-energy audio specifications. The idea is to unify the stereo and mono audio profiles
and replace both A2DP and HFP. It has a better sound quality with the new IC3 codec. And it has an isoconus radio channel, sorry,
to guarantee bandwidth and minimal delay. By default, it is able to support bidirectional audio for every usage. It supports multi-stream support, replacing two wireless.
It also supports hearing aids. And with the new O'Rourke mode, you are able to broadcast audio without interaction between the transmitter and the receivers. This ends up in a lot of new profiles and specifications. V1 and V2 are already supported by BlueZ and Pipewire.
But as there is not so many devices on the market to test with, they are still set as experimental in both BlueZ and Pipewire and in some configuration to be set if you want to use them.
Regarding the broadcast support, it is already supported. The low level is already supported in the kernel. But there is still some work to do in BlueZ and Pipewire. And mostly, find the correct UX to be able to share audio or to flex the broadcast you want to listen to. Thank you.