Hello, I'm Frédéric Danisse, software engineer at Colabora, and I will present you the Bluetooth
test in wire pramber, and per-pramber, and wire pramber.
By prior, the low latency, gravity processing engine's attempt is to handle the audio and
video streams.
It is intended to replace both Pulse Audio and Jack Audio systems.
Wire pramber is in charge of creating the audio and video notes, and the link between
the notes according to the policies defined by the system or the users.
Both of them are designed for desktop.
Main distribution is 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
ANSI, mono and bidirectional profiles, like which is ANSI profile, and it's said profile,
the latter less and less used.
For the Bluetooth classic audio profiles, A2DP stands for Advanced Audio Distribution Profiles.
It aims to manage audio streaming between media player and headset or speakers.
And in this table, you can see the supported codecs.
The first one is SBC codec, which is low complexity, fast, and low C, but is implemented on all
devices.
The A2DP specification allows other codecs, like AAC, which is optional and not implemented
on all devices.
And this specification allows also other codecs not defined in this specification.
Most of them have been implemented to improve the audio quality, but are not supported by
all devices.
For example, the EPTX family of codecs can be found on Qualcomm devices or need licensing
from Qualcomm, or the LDAC codec is found on Sony devices.
In PipeWire, we use this ability to add some other codecs like OPUS, which is an open format,
or LC3PUS, which is an enhanced version of the codec using LE audio, which we'll talk
later.
Some founders have the ability to do bidirectional audio on A2DP with a fast stream codec, which
is an evolution of the SBC codec, or the EPTX lossless codec, which is one of the EPTX
family.
Just one other thing.
Last year, we were able to pass the Bluetooth qualification using both PipeWire and WirePobler
on the Steam Deck.
HFP stands for Ans3 Profile.
It is used for communication usage, but unlike the A2DP one, it also defines the commands
to interact with the telephony using a set of 80 commands.
This can be done with external demons like HSP, HFPD, or Ophono, Ophono adding a complete
support for the modem, or with a native backend, which is only a limited set of 80 commands
allowing to complete the connection with Bluetooth devices.
Yes.
And this can be used with configuring application.
Last year, we had to the native backend the support for modem manager allowing to have
a complete telephony usage from inside the Bluetooth, from inside PipeWire.
So with Ophono, our modem manager, PipeWire has a complete telephony support to the mobile
distribution device, mobile device distribution.
HFP supports two codecs, the mount datory one, which is CVSD, which is an urban audio connection.
In this case, in this case, yes, for the CVSD, the audio is sent directly to the Bluetooth
chipset, which will encode the data through the blue Cisco socket.
And the second codec is MSBC, which is optional, it's a fixed configuration of SBC.
But it needs both support from Kernel and the chipset.
And it is automatically detected during runtime by PipeWire.
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 PipeWire to only use this
code socket to connect and configure the remote, the link to the remote device.
While PipeWire will create pass-through nodes allowing the user to select the Bluetooth remote device as an audio output.
And then the data is sent to the audio card, which plays them to the Bluetooth chipset,
which will encode and send the data over the air.
Now I will 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.
It has an Isoconus radio channel 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.
With the new Holocaust mode, you are able to broadcast audio without interaction between the transmitter and the receivers.
These send-ups in a lot of new profiles and specifications.
The ones in blue are already supported by BlueZ and PipeWire.
But there are 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 channel,
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 select the broadcast you want to listen to.
Thank you.