[00:00.000 --> 00:12.000]  Hello, I'm Frédéric Danisse, software engineer at Colabora, and I will present you the Bluetooth
[00:12.000 --> 00:16.440]  test in wire pramber, and per-pramber, and wire pramber.
[00:16.440 --> 00:24.400]  By prior, the low latency, gravity processing engine's attempt is to handle the audio and
[00:24.400 --> 00:26.400]  video streams.
[00:26.400 --> 00:35.400]  It is intended to replace both Pulse Audio and Jack Audio systems.
[00:35.400 --> 00:42.400]  Wire pramber is in charge of creating the audio and video notes, and the link between
[00:42.400 --> 00:49.400]  the notes according to the policies defined by the system or the users.
[00:49.400 --> 00:55.400]  Both of them are designed for desktop.
[00:55.400 --> 01:01.400]  Main distribution is switching to them, or to the embedded.
[01:01.400 --> 01:08.400]  More specifically for Bluetooth, the Bluetooth classic audio profiles are divided in two
[01:08.400 --> 01:17.400]  main categories, the mono, the stereo, and mostly unidirectional audio streaming called
[01:17.400 --> 01:28.400]  ANSI, mono and bidirectional profiles, like which is ANSI profile, and it's said profile,
[01:28.400 --> 01:35.400]  the latter less and less used.
[01:35.400 --> 01:42.400]  For the Bluetooth classic audio profiles, A2DP stands for Advanced Audio Distribution Profiles.
[01:42.400 --> 01:51.400]  It aims to manage audio streaming between media player and headset or speakers.
[01:51.400 --> 01:58.400]  And in this table, you can see the supported codecs.
[01:58.400 --> 02:08.400]  The first one is SBC codec, which is low complexity, fast, and low C, but is implemented on all
[02:08.400 --> 02:09.400]  devices.
[02:09.400 --> 02:20.400]  The A2DP specification allows other codecs, like AAC, which is optional and not implemented
[02:20.400 --> 02:22.400]  on all devices.
[02:22.400 --> 02:28.400]  And this specification allows also other codecs not defined in this specification.
[02:28.400 --> 02:35.400]  Most of them have been implemented to improve the audio quality, but are not supported by
[02:35.400 --> 02:36.400]  all devices.
[02:36.400 --> 02:47.400]  For example, the EPTX family of codecs can be found on Qualcomm devices or need licensing
[02:47.400 --> 02:54.400]  from Qualcomm, or the LDAC codec is found on Sony devices.
[02:54.400 --> 03:01.400]  In PipeWire, we use this ability to add some other codecs like OPUS, which is an open format,
[03:01.400 --> 03:08.400]  or LC3PUS, which is an enhanced version of the codec using LE audio, which we'll talk
[03:08.400 --> 03:11.400]  later.
[03:11.400 --> 03:20.400]  Some founders have the ability to do bidirectional audio on A2DP with a fast stream codec, which
[03:20.400 --> 03:28.400]  is an evolution of the SBC codec, or the EPTX lossless codec, which is one of the EPTX
[03:28.400 --> 03:32.400]  family.
[03:32.400 --> 03:34.400]  Just one other thing.
[03:34.400 --> 03:42.400]  Last year, we were able to pass the Bluetooth qualification using both PipeWire and WirePobler
[03:42.400 --> 03:45.400]  on the Steam Deck.
[03:45.400 --> 03:47.400]  HFP stands for Ans3 Profile.
[03:47.400 --> 03:57.400]  It is used for communication usage, but unlike the A2DP one, it also defines the commands
[03:57.400 --> 04:02.400]  to interact with the telephony using a set of 80 commands.
[04:02.400 --> 04:09.400]  This can be done with external demons like HSP, HFPD, or Ophono, Ophono adding a complete
[04:09.400 --> 04:17.400]  support for the modem, or with a native backend, which is only a limited set of 80 commands
[04:17.400 --> 04:26.400]  allowing to complete the connection with Bluetooth devices.
[04:26.400 --> 04:28.400]  Yes.
[04:28.400 --> 04:33.400]  And this can be used with configuring application.
[04:33.400 --> 04:39.400]  Last year, we had to the native backend the support for modem manager allowing to have
[04:39.400 --> 04:48.400]  a complete telephony usage from inside the Bluetooth, from inside PipeWire.
[04:48.400 --> 04:55.400]  So with Ophono, our modem manager, PipeWire has a complete telephony support to the mobile
[04:55.400 --> 05:01.400]  distribution device, mobile device distribution.
[05:01.400 --> 05:11.400]  HFP supports two codecs, the mount datory one, which is CVSD, which is an urban audio connection.
[05:11.400 --> 05:23.400]  In this case, in this case, yes, for the CVSD, the audio is sent directly to the Bluetooth
[05:23.400 --> 05:30.400]  chipset, which will encode the data through the blue Cisco socket.
[05:30.400 --> 05:43.400]  And the second codec is MSBC, which is optional, it's a fixed configuration of SBC.
[05:43.400 --> 05:49.400]  But it needs both support from Kernel and the chipset.
[05:49.400 --> 05:56.400]  And it is automatically detected during runtime by PipeWire.
[05:56.400 --> 06:07.400]  But on some hardware devices, the chipset has a direct audio link connected to an audio card
[06:07.400 --> 06:09.400]  or to the modem.
[06:09.400 --> 06:19.400]  To be able to support it, we add a hardware scope of load mode, which allows PipeWire to only use this
[06:19.400 --> 06:27.400]  code socket to connect and configure the remote, the link to the remote device.
[06:27.400 --> 06:39.400]  While PipeWire will create pass-through nodes allowing the user to select the Bluetooth remote device as an audio output.
[06:39.400 --> 06:47.400]  And then the data is sent to the audio card, which plays them to the Bluetooth chipset,
[06:47.400 --> 06:53.400]  which will encode and send the data over the air.
[06:53.400 --> 06:59.400]  Now I will do a quick overview of the new low-energy audio specifications.
[06:59.400 --> 07:10.400]  The idea is to unify the stereo and mono audio profiles and replace both A2DP and HFP.
[07:10.400 --> 07:15.400]  It has a better sound quality with the new IC3 codec.
[07:15.400 --> 07:30.400]  It has an Isoconus radio channel to guarantee bandwidth and minimal delay.
[07:30.400 --> 07:37.400]  By default, it is able to support bidirectional audio for every usage.
[07:37.400 --> 07:42.400]  It supports multi-stream support, replacing two wireless.
[07:42.400 --> 07:45.400]  It also supports hearing aids.
[07:45.400 --> 07:53.400]  With the new Holocaust mode, you are able to broadcast audio without interaction between the transmitter and the receivers.
[07:53.400 --> 07:59.400]  These send-ups in a lot of new profiles and specifications.
[07:59.400 --> 08:06.400]  The ones in blue are already supported by BlueZ and PipeWire.
[08:06.400 --> 08:15.400]  But there are not so many devices on the market to test with, they are still set as experimental in both BlueZ and PipeWire,
[08:15.400 --> 08:20.400]  and in some configuration to be set if you want to use them.
[08:20.400 --> 08:26.400]  Regarding the broadcast support, it is already supported, the low-level is already supported in the channel,
[08:26.400 --> 08:30.400]  but there is still some work to do in BlueZ and PipeWire,
[08:30.400 --> 08:39.400]  and mostly find the correct UX to be able to share audio or to select the broadcast you want to listen to.
[08:39.400 --> 09:01.400]  Thank you.