| Message ID | 20200419234937.4zozkqgpt557m3o6@pali (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Marcel Holtmann |
| Headers | show |
| Series | Bluetooth: Allow to use configure SCO socket codec parameters | expand |
Hi Pali, On Sun, Apr 19, 2020 at 4:49 PM Pali Rohár <pali@kernel.org> wrote: > > Hello! > > I'm sending next attempt for userspace <--> kernel API for specifying > connection settings of SCO socket. I was thinking more about it and I > was able to remove some members from struct bt_voice_setup which are not > needed for Linux SCO sockets (e.g. specifying different routing then > over HCI). > > Here is this API: > > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h > index fabee6db0abb..f1f482bdf526 100644 > --- a/include/net/bluetooth/bluetooth.h > +++ b/include/net/bluetooth/bluetooth.h > @@ -122,6 +122,37 @@ struct bt_voice { > #define BT_SNDMTU 12 > #define BT_RCVMTU 13 > > +#define BT_VOICE_SETUP 14 > + > +#define BT_VOICE_PKT_TYPE_CAP_SCO BIT(0) > +#define BT_VOICE_PKT_TYPE_CAP_ESCO BIT(1) > +struct bt_voice_pkt_type { > + __u8 capability; /* bitmask of BT_VOICE_PKT_TYPE_CAP_* */ > + __u8 retrans_effort; > + __u16 pkt_type; > + __u16 max_latency; > +}; > +struct bt_voice_setup { > + __u32 tx_bandwidth; > + __u32 rx_bandwidth; > + __u16 tx_codec_frame_size; > + __u16 rx_codec_frame_size; > + __u8 tx_coding_format[5]; > + __u8 rx_coding_format[5]; > + __u8 input_coding_format[5]; > + __u8 output_coding_format[5]; > + __u16 input_coded_data_size; > + __u16 output_coded_data_size; > + __u8 input_pcm_data_format; > + __u8 output_pcm_data_format; > + __u8 input_pcm_msb_position; > + __u8 output_pcm_msb_position; > + __u32 input_bandwidth; > + __u32 output_bandwidth; > + __u32 pkt_types_count; > + struct bt_voice_pkt_type pkt_types[]; > +}; We might be better off splitting the local only, coding format related, from the QoS that goes over the air, afaik one don't have to reprogram the coding format for every connection, or perhpas Im confusing with how ISO commands works in this regard. > __printf(1, 2) > void bt_info(const char *fmt, ...); > __printf(1, 2) > > > Structure specify settings for exactly one codec. > > Meaning of those members is same as for Enhanced Setup Synchronous > Connection HCI command. > > Let me a bit explain it: > > Members tx_bandwidth, rx_bandwidth, tx_codec_frame_size, > rx_codec_frame_size, tx_coding_format and rx_coding_format specify AIR > codec and all of them are needed to correctly describe codec used by > bluetooth adapter to transmit data over the air. All of these members > are also part of Enhanced Setup Synchronous Connection command and > application which want to use vendor codec needs to control of all them. > > Members input_coding_format, output_coding_format, > input_coded_data_size, output_coded_data_size, input_bandwidth and > output_bandwidth describe LOCAL codec, format of audio data which is > passed by application to the bluetooth adapter. It does not have to be > same as AIR codec and in this case bluetooth adapter is doing HW > encoding/decoding. Does that assumes that we can only have one local codec active at time? How about 2 devices connected, one using CVSD and another mSBC? If we can't configure the hardware codecs on a per connection basis then chances are this won't be that useful for things like a desktop environment as in order to support multiple devices connecting, with or without wideband speech, we would have to switch to sofware enconding/deconding, but perhaps Im wrong and it indeed possible but I doubt that because HW encoding/decoding normally use dedicated DSP and I don't think that would be able to deal with different codecs in parallel, which means that in order to use HW encoding/decoding we would have to artificially limit the number of SCO connection to 1 to avoid random drop outs when using HW codecs. > When coding_format is PCM then additional parameters for PCM format > needs to be specified, more exactly they are in members: > input_pcm_data_format, output_pcm_data_format, input_pcm_msb_position > and output_pcm_msb_position. > > For modern audio applications is is required to control all of these PCM > parameters as audio application does not have to reencode everything to > one format (e.g. 8Hz/s16le), but let bluetooth adapter to do reencoding > at HW level. > > The last pkt_types[] array (with pkt_types_count items) defines what > type bluetooth packets and SCO/eSCO mode can be used with particular > codec. > > So all members of that structure are needed for userspace audio > applications (e.g. pulseaudio) and without them it is not possible > implement custom vendor SCO codecs which are already used in bluetooth > headsets. Also without them it is not possible to use HW encoders in > bluetooth chip, e.g. mSBC and applications are forced to use in-software > encoding/decoding which may be slow or increase latency or power usage. > > And here are some example how to use it: > > SCO socket that would accept 16kHz PCM s16le data and bluetooth chip > would encode it to mSBC over the air. > > #define HCI_CODING_FORMAT_PCM 0x04 > #define HCI_CODING_FORMAT_MSBC 0x05 > #define HCI_PCM_DATA_FORMAT_2COMP 0x02 > static const struct bt_voice_setup voice_setup = { > .tx_bandwidth = 8000, > .rx_bandwidth = 8000, > .tx_codec_frame_size = 60, > .rx_codec_frame_size = 60, > .tx_coding_format = { HCI_CODING_FORMAT_MSBC }, > .rx_coding_format = { HCI_CODING_FORMAT_MSBC }, > .input_coding_format = { HCI_CODING_FORMAT_PCM }, > .output_coding_format = { HCI_CODING_FORMAT_PCM }, > .input_coded_data_size = 16, > .output_coded_data_size = 16, > .input_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, > .output_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, > .input_pcm_msb_position = 0, > .output_pcm_msb_position = 0, > .input_bandwidth = 32000, > .output_bandwidth = 32000, > .pkt_types_count = 2, > .pkt_types = { > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d }, /* T2 */ > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK | ESCO_EV3, 0x0008 }, /* T1 */ > }, > }; > int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); > bind(fd, ...); > setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); > connect(fd, ...); > > > SCO socket that would accept AuriStream codec from application and tell > bluetooth chip to pass-throu as is over the air: > > #define HCI_CODING_FORMAT_TRANSPARENT 0x03 > static const struct bt_voice_setup voice_setup = { > .tx_bandwidth = 4000, > .rx_bandwidth = 4000, > .tx_codec_frame_size = 60, > .rx_codec_frame_size = 60, > .tx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > .rx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > .input_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > .output_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > .input_coded_data_size = 8, > .output_coded_data_size = 8, > .input_pcm_data_format = 0, > .output_pcm_data_format = 0, > .input_pcm_msb_position = 0, > .output_pcm_msb_position = 0, > .input_bandwidth = 4000, > .output_bandwidth = 4000, > .pkt_types_count = 1, > .pkt_types = { > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, 0x003F, 16 }, > }, > }; > int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); > bind(fd, ...); > setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); > connect(fd, ...); > > > That API is designed for Enhanced Setup Synchronous Connection HCI > command, but can also be used by plain Setup Synchronous Connection HCI > command. Plain version has just reduced set of features and basically > instead of AIR codec members and LOCAL codec members use just one u16 > member voice_setting, which is just subset of all those possible > Enhanced settings and can be generated from them. E.g. transparent > coding format is encoded in voice_setting as 0x0003, usage of CVSD HW > encoder from pcm_s16le_8kHz as 0x0060, but e.g. usage of mSBC HW encoder > is not possible to specify. > > Please let me know what do you think about it. Thanks
Hello! On Monday 20 April 2020 16:54:39 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sun, Apr 19, 2020 at 4:49 PM Pali Rohár <pali@kernel.org> wrote: > > > > Hello! > > > > I'm sending next attempt for userspace <--> kernel API for specifying > > connection settings of SCO socket. I was thinking more about it and I > > was able to remove some members from struct bt_voice_setup which are not > > needed for Linux SCO sockets (e.g. specifying different routing then > > over HCI). > > > > Here is this API: > > > > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h > > index fabee6db0abb..f1f482bdf526 100644 > > --- a/include/net/bluetooth/bluetooth.h > > +++ b/include/net/bluetooth/bluetooth.h > > @@ -122,6 +122,37 @@ struct bt_voice { > > #define BT_SNDMTU 12 > > #define BT_RCVMTU 13 > > > > +#define BT_VOICE_SETUP 14 > > + > > +#define BT_VOICE_PKT_TYPE_CAP_SCO BIT(0) > > +#define BT_VOICE_PKT_TYPE_CAP_ESCO BIT(1) > > +struct bt_voice_pkt_type { > > + __u8 capability; /* bitmask of BT_VOICE_PKT_TYPE_CAP_* */ > > + __u8 retrans_effort; > > + __u16 pkt_type; > > + __u16 max_latency; > > +}; > > +struct bt_voice_setup { > > + __u32 tx_bandwidth; > > + __u32 rx_bandwidth; > > + __u16 tx_codec_frame_size; > > + __u16 rx_codec_frame_size; > > + __u8 tx_coding_format[5]; > > + __u8 rx_coding_format[5]; > > + __u8 input_coding_format[5]; > > + __u8 output_coding_format[5]; > > + __u16 input_coded_data_size; > > + __u16 output_coded_data_size; > > + __u8 input_pcm_data_format; > > + __u8 output_pcm_data_format; > > + __u8 input_pcm_msb_position; > > + __u8 output_pcm_msb_position; > > + __u32 input_bandwidth; > > + __u32 output_bandwidth; > > + __u32 pkt_types_count; > > + struct bt_voice_pkt_type pkt_types[]; > > +}; Maybe I should write that above setsockopt(BT_VOICE_SETUP=14) call is a replacement for setsockopt(BT_VOICE=13). It is used in the same way. > We might be better off splitting the local only, coding format > related, from the QoS that goes over the air, afaik one don't have to > reprogram the coding format for every connection, or perhpas Im > confusing with how ISO commands works in this regard. Well, when using HFP profile, specifying coding format is needed for every connection based on how both sides (AG and HF) decide on the final codec. Also e.g. user can decide to choose / change different codec (via audio application e.g. pulseaudio) if current selected is broken / does not work with particular headset (yes, there are such). And QoS is bound with air coding format for some codecs (e.g. AuriStream), so it should not be separated. Plus old bluetooth adapters do not support hardware mSBC encoding, so for mSBC you need to specify both local part and air coding format. So based on this I do not suggest to split this structure. Otherwise it just complicate userspace application support, which will *always* need to call methods to set all those settings. Basically I do not see a reason for (new/modern) audio application when it should want to configure/change just local part or just air coding format. Audio application needs to always configure all of them when creating a new connection. Just to note when nothing is specified, then default settings are used like before (so CVSD HW encoding), to not break any existing applications. Also setsockopt(BT_VOICE=13) is still support and it would be (internally by kernel) converted to setsockopt(BT_VOICE_SETUP=14) call, so again no application would be broken which still would use just BT_VOICE=13. > > __printf(1, 2) > > void bt_info(const char *fmt, ...); > > __printf(1, 2) > > > > > > Structure specify settings for exactly one codec. > > > > Meaning of those members is same as for Enhanced Setup Synchronous > > Connection HCI command. > > > > Let me a bit explain it: > > > > Members tx_bandwidth, rx_bandwidth, tx_codec_frame_size, > > rx_codec_frame_size, tx_coding_format and rx_coding_format specify AIR > > codec and all of them are needed to correctly describe codec used by > > bluetooth adapter to transmit data over the air. All of these members > > are also part of Enhanced Setup Synchronous Connection command and > > application which want to use vendor codec needs to control of all them. > > > > Members input_coding_format, output_coding_format, > > input_coded_data_size, output_coded_data_size, input_bandwidth and > > output_bandwidth describe LOCAL codec, format of audio data which is > > passed by application to the bluetooth adapter. It does not have to be > > same as AIR codec and in this case bluetooth adapter is doing HW > > encoding/decoding. > > Does that assumes that we can only have one local codec active at > time? No, there is no such limitation. Codec setting, like for setsockopt(BT_VOICE=13) is per-socket. See usage, setsockopt is set for file descriptor of created SCO socket. It is *not* global like "hciconfig hci0 voice" command. > How about 2 devices connected, one using CVSD and another mSBC? > If we can't configure the hardware codecs on a per connection basis > then chances are this won't be that useful for things like a desktop > environment as in order to support multiple devices connecting, with > or without wideband speech, we would have to switch to sofware > enconding/deconding, but perhaps Im wrong and it indeed possible but I > doubt that because HW encoding/decoding normally use dedicated DSP and > I don't think that would be able to deal with different codecs in > parallel, which means that in order to use HW encoding/decoding we > would have to artificially limit the number of SCO connection to 1 to > avoid random drop outs when using HW codecs. There is no need to do any limitation. Codec setting is per connection and every SCO connection can configure its own codec. So there is out-of-box multidevice support via this API and (Enhanced) Setup Synchronous Connection HCI command. > > When coding_format is PCM then additional parameters for PCM format > > needs to be specified, more exactly they are in members: > > input_pcm_data_format, output_pcm_data_format, input_pcm_msb_position > > and output_pcm_msb_position. > > > > For modern audio applications is is required to control all of these PCM > > parameters as audio application does not have to reencode everything to > > one format (e.g. 8Hz/s16le), but let bluetooth adapter to do reencoding > > at HW level. > > > > The last pkt_types[] array (with pkt_types_count items) defines what > > type bluetooth packets and SCO/eSCO mode can be used with particular > > codec. > > > > So all members of that structure are needed for userspace audio > > applications (e.g. pulseaudio) and without them it is not possible > > implement custom vendor SCO codecs which are already used in bluetooth > > headsets. Also without them it is not possible to use HW encoders in > > bluetooth chip, e.g. mSBC and applications are forced to use in-software > > encoding/decoding which may be slow or increase latency or power usage. > > > > And here are some example how to use it: > > > > SCO socket that would accept 16kHz PCM s16le data and bluetooth chip > > would encode it to mSBC over the air. > > > > #define HCI_CODING_FORMAT_PCM 0x04 > > #define HCI_CODING_FORMAT_MSBC 0x05 > > #define HCI_PCM_DATA_FORMAT_2COMP 0x02 > > static const struct bt_voice_setup voice_setup = { > > .tx_bandwidth = 8000, > > .rx_bandwidth = 8000, > > .tx_codec_frame_size = 60, > > .rx_codec_frame_size = 60, > > .tx_coding_format = { HCI_CODING_FORMAT_MSBC }, > > .rx_coding_format = { HCI_CODING_FORMAT_MSBC }, > > .input_coding_format = { HCI_CODING_FORMAT_PCM }, > > .output_coding_format = { HCI_CODING_FORMAT_PCM }, > > .input_coded_data_size = 16, > > .output_coded_data_size = 16, > > .input_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, > > .output_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, > > .input_pcm_msb_position = 0, > > .output_pcm_msb_position = 0, > > .input_bandwidth = 32000, > > .output_bandwidth = 32000, > > .pkt_types_count = 2, > > .pkt_types = { > > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d }, /* T2 */ > > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK | ESCO_EV3, 0x0008 }, /* T1 */ > > }, > > }; > > int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); > > bind(fd, ...); > > setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); > > connect(fd, ...); > > > > > > SCO socket that would accept AuriStream codec from application and tell > > bluetooth chip to pass-throu as is over the air: > > > > #define HCI_CODING_FORMAT_TRANSPARENT 0x03 > > static const struct bt_voice_setup voice_setup = { > > .tx_bandwidth = 4000, > > .rx_bandwidth = 4000, > > .tx_codec_frame_size = 60, > > .rx_codec_frame_size = 60, > > .tx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > > .rx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > > .input_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > > .output_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, > > .input_coded_data_size = 8, > > .output_coded_data_size = 8, > > .input_pcm_data_format = 0, > > .output_pcm_data_format = 0, > > .input_pcm_msb_position = 0, > > .output_pcm_msb_position = 0, > > .input_bandwidth = 4000, > > .output_bandwidth = 4000, > > .pkt_types_count = 1, > > .pkt_types = { > > { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, 0x003F, 16 }, > > }, > > }; > > int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); > > bind(fd, ...); > > setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); > > connect(fd, ...); And to make it clear usage for accepted from listening socket is following: int listening_fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); bind(listening_fd, ...); int one = 1; setsockopt(listening_fd, SOL_BLUETOOTH, BT_DEFER_SETUP, &one, sizeof(one)); listen(listening_fd, ...); int fd = accept(listening_fd, ...); setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); char dummy; read(fd, &dummy, 1); It is exactly same as for setsockopt(BT_VOICE=13). You first need to enable BT_DEFER_SETUP which allows to configure per-accepted-socket SCO configuration of socket. Last read syscall cause to establish new SCO connection with specified voice_setup parameters (exactly like of BT_VOICE=13 is used). > > > > That API is designed for Enhanced Setup Synchronous Connection HCI > > command, but can also be used by plain Setup Synchronous Connection HCI > > command. Plain version has just reduced set of features and basically > > instead of AIR codec members and LOCAL codec members use just one u16 > > member voice_setting, which is just subset of all those possible > > Enhanced settings and can be generated from them. E.g. transparent > > coding format is encoded in voice_setting as 0x0003, usage of CVSD HW > > encoder from pcm_s16le_8kHz as 0x0060, but e.g. usage of mSBC HW encoder > > is not possible to specify. > > > > Please let me know what do you think about it. Thanks > > > > -- > Luiz Augusto von Dentz
Pali Rohár wrote on 20.04.20 г. 2:49 ч.:
<...>
> Please let me know what do you think about it. Thanks
Hello,
Is anybody from bluetooth maintainers able to review and move this
forward? Seems like recent bt headsets are unusable under Linux for
audio conferences at the moment. I have a few that only work as playback
devices.
Pali is doing a huge job trying to tackle the issues in all various
places. This patch appears necessary to get reasonable quality out of
the headsets as the default codec sounds horrible (I mean for HSP/HFP mode).
Thus I and I assume all headphones users will appreciate very much any
support to get things moving forward.
I hope my message finds everybody in a good situation.
On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: > > Pali Rohár wrote on 20.04.20 г. 2:49 ч.: > <...> > > Please let me know what do you think about it. Thanks > > <...> > Thus I and I assume all headphones users will appreciate very much any > support to get things moving forward. To add to what Aleksandar said, a number of us would be more than willing to help out in any way we can. Certainly myself, but I expect a number of others, too. We have bluetooth cards in our computers with wideband speech support. We have bluetooth headsets with wideband speech support. Many of the links in the chain are in place. If we can continue building that chain then we can have a higher quality experience in this era of teleconferencing in particular. So if there's anything we can lend a hand with, then please let us know and we can see this through. Cheers, -Andrew
Hi Andrew, Aleksandar, On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote: > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: > > > > Pali Rohár wrote on 20.04.20 г. 2:49 ч.: > > <...> > > > Please let me know what do you think about it. Thanks > > > > <...> > > Thus I and I assume all headphones users will appreciate very much any > > support to get things moving forward. > > To add to what Aleksandar said, a number of us would be more than > willing to help out in any way we can. Certainly myself, but I expect > a number of others, too. We have bluetooth cards in our computers > with wideband speech support. We have bluetooth headsets with > wideband speech support. Many of the links in the chain are in place. > If we can continue building that chain then we can have a higher > quality experience in this era of teleconferencing in particular. > > So if there's anything we can lend a hand with, then please let us > know and we can see this through. Just to be clear here, WBS is already supported what is not supported is hardware based codecs, we spend a lot of time enabling WBS on oFono but it looks like people are now trying to come with their own solutions and complaining about lack of WBS is not really justified since the combination of BlueZ + oFono has been in use by the car industry for years but desktop folks has not been interested in a proper HFP solution so instead we have modem manager, network manager, etc, which doesn't even cover all desktop use cases properly as you are experience first hand here.
Luiz Augusto von Dentz wrote on 16.05.20 г. 2:08 ч.: > Hi Andrew, Aleksandar, > > On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote: >> >> On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: >>> >>> Pali Rohár wrote on 20.04.20 г. 2:49 ч.: >>> <...> >>>> Please let me know what do you think about it. Thanks >>> >>> <...> >>> Thus I and I assume all headphones users will appreciate very much any >>> support to get things moving forward. >> >> To add to what Aleksandar said, a number of us would be more than >> willing to help out in any way we can. Certainly myself, but I expect >> a number of others, too. We have bluetooth cards in our computers >> with wideband speech support. We have bluetooth headsets with >> wideband speech support. Many of the links in the chain are in place. >> If we can continue building that chain then we can have a higher >> quality experience in this era of teleconferencing in particular. >> >> So if there's anything we can lend a hand with, then please let us >> know and we can see this through. > > Just to be clear here, WBS is already supported what is not supported > is hardware based codecs, we spend a lot of time enabling WBS on oFono > but it looks like people are now trying to come with their own > solutions and complaining about lack of WBS is not really justified > since the combination of BlueZ + oFono has been in use by the car > industry for years but desktop folks has not been interested in a > proper HFP solution so instead we have modem manager, network manager, > etc, which doesn't even cover all desktop use cases properly as you > are experience first hand here. Hi Luiz. I'm not sure arguing on no-technical details here will help. Still I feel it is important to say that I don't find it justified to call it *complaining* when somebody is proposing patches which apparently enable missing functionality and avoid necessity for running with root privileges. Now if patch is bad on the technical level, that would be valid point to reject it. I see Pali trying to address any raised concerns though so I hope it is alright. But rejecting the patches on premises that it is not necessary for solution X and blocking any alternative solutions is IMO unfair. The needs of car industry are very different from the needs of desktop users. I'm not a kernel or bluetooth developer but as a user of Network Manager (that you gave as an example) I can say that it changed a lot making network management at single point and changing networks easily while moving around. I've been a network admin in the past and it has not been a problem to only use static network setup. As a laptop user though things dramatically changed. Same goes with Pulse audio/ALSA. While everything could be done with ALSA it has been much harder and up to the skills of a very few people to manage audio inputs/outputs/redirection properly. Certainly since Pulse became stable I never missed asoundrc. Thus for users it is important what desktop developers are providing. While we can assume they are all idiots doing things in all the wrong ways, I'd rather prefer to think they may have a point when choosing certain technology over another. So I'm asking anybody that it depends on, to look from the desktop user perspective and help move this forward. Thank you.
On Friday 15 May 2020 16:08:45 Luiz Augusto von Dentz wrote: > Hi Andrew, Aleksandar, > > On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote: > > > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: > > > > > > Pali Rohár wrote on 20.04.20 г. 2:49 ч.: > > > <...> > > > > Please let me know what do you think about it. Thanks > > > > > > <...> > > > Thus I and I assume all headphones users will appreciate very much any > > > support to get things moving forward. > > > > To add to what Aleksandar said, a number of us would be more than > > willing to help out in any way we can. Certainly myself, but I expect > > a number of others, too. We have bluetooth cards in our computers > > with wideband speech support. We have bluetooth headsets with > > wideband speech support. Many of the links in the chain are in place. > > If we can continue building that chain then we can have a higher > > quality experience in this era of teleconferencing in particular. > > > > So if there's anything we can lend a hand with, then please let us > > know and we can see this through. > > Just to be clear here, WBS is already supported what is not supported > is hardware based codecs, Luiz, this is not truth. What is not supported are also custom parameters and custom codecs; including hardware mSBC support. Last year I started this thread because kernel blocks usage of AuriStream codec in any form (software or hardware). And AuriStream is supported by many bluetooth headsets and should have better quality than CVSD codec. > we spend a lot of time enabling WBS on oFono > but it looks like people are now trying to come with their own > solutions and complaining about lack of WBS is not really justified > since the combination of BlueZ + oFono has been in use by the car > industry for years but desktop folks has not been interested in a > proper HFP solution so instead we have modem manager, network manager, > etc, which doesn't even cover all desktop use cases properly as you > are experience first hand here. Apparently all people who are periodically writing me private emails are not interested in car industry, but are ordinary desktop / laptop users and ofono is not ready for these use cases and are not going to fix it. I guess that Aleksander and Andrew too are desktop / laptop users and not from car industry.
Hi Pali, On Sat, May 16, 2020 at 12:53 AM Pali Rohár <pali@kernel.org> wrote: > > On Friday 15 May 2020 16:08:45 Luiz Augusto von Dentz wrote: > > Hi Andrew, Aleksandar, > > > > On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote: > > > > > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: > > > > > > > > Pali Rohár wrote on 20.04.20 г. 2:49 ч.: > > > > <...> > > > > > Please let me know what do you think about it. Thanks > > > > > > > > <...> > > > > Thus I and I assume all headphones users will appreciate very much any > > > > support to get things moving forward. > > > > > > To add to what Aleksandar said, a number of us would be more than > > > willing to help out in any way we can. Certainly myself, but I expect > > > a number of others, too. We have bluetooth cards in our computers > > > with wideband speech support. We have bluetooth headsets with > > > wideband speech support. Many of the links in the chain are in place. > > > If we can continue building that chain then we can have a higher > > > quality experience in this era of teleconferencing in particular. > > > > > > So if there's anything we can lend a hand with, then please let us > > > know and we can see this through. > > > > Just to be clear here, WBS is already supported what is not supported > > is hardware based codecs, > > Luiz, this is not truth. What is not supported are also custom > parameters and custom codecs; including hardware mSBC support. > > Last year I started this thread because kernel blocks usage of > AuriStream codec in any form (software or hardware). > > And AuriStream is supported by many bluetooth headsets and should have > better quality than CVSD codec. You are still talking about hardware codec not WBS which is a HFP feature, without a proper HFP implementation it is not even possible to select AuriStream so it beats me why you want to bring that up. > > we spend a lot of time enabling WBS on oFono > > but it looks like people are now trying to come with their own > > solutions and complaining about lack of WBS is not really justified > > since the combination of BlueZ + oFono has been in use by the car > > industry for years but desktop folks has not been interested in a > > proper HFP solution so instead we have modem manager, network manager, > > etc, which doesn't even cover all desktop use cases properly as you > > are experience first hand here. > > Apparently all people who are periodically writing me private emails are > not interested in car industry, but are ordinary desktop / laptop users > and ofono is not ready for these use cases and are not going to fix it. > I guess that Aleksander and Andrew too are desktop / laptop users and > not from car industry. Once you written and qualified your own HFP implementation we can start talking about integrating it for desktop / laptop use, otherwise the _only_ real option here is oFono, whether that requires a modem or not is a different history, something that perhaps we should take on to oFono to enable VoIP application to act as modems but that needs to be discussed with oFono community.
On Monday 18 May 2020 09:43:55 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sat, May 16, 2020 at 12:53 AM Pali Rohár <pali@kernel.org> wrote: > > > > On Friday 15 May 2020 16:08:45 Luiz Augusto von Dentz wrote: > > > Hi Andrew, Aleksandar, > > > > > > On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote: > > > > > > > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote: > > > > > > > > > > Pali Rohár wrote on 20.04.20 г. 2:49 ч.: > > > > > <...> > > > > > > Please let me know what do you think about it. Thanks > > > > > > > > > > <...> > > > > > Thus I and I assume all headphones users will appreciate very much any > > > > > support to get things moving forward. > > > > > > > > To add to what Aleksandar said, a number of us would be more than > > > > willing to help out in any way we can. Certainly myself, but I expect > > > > a number of others, too. We have bluetooth cards in our computers > > > > with wideband speech support. We have bluetooth headsets with > > > > wideband speech support. Many of the links in the chain are in place. > > > > If we can continue building that chain then we can have a higher > > > > quality experience in this era of teleconferencing in particular. > > > > > > > > So if there's anything we can lend a hand with, then please let us > > > > know and we can see this through. > > > > > > Just to be clear here, WBS is already supported what is not supported > > > is hardware based codecs, > > > > Luiz, this is not truth. What is not supported are also custom > > parameters and custom codecs; including hardware mSBC support. > > > > Last year I started this thread because kernel blocks usage of > > AuriStream codec in any form (software or hardware). > > > > And AuriStream is supported by many bluetooth headsets and should have > > better quality than CVSD codec. > > You are still talking about hardware codec not WBS which is a HFP > feature, without a proper HFP implementation it is not even possible > to select AuriStream so it beats me why you want to bring that up. AuriStream works also in HSP profile and I already implemented negotiation for AuriStream codec for both HSP and HFP profiles. The only missing part is to unblock kernel to allow usage of AuriStream. > > > we spend a lot of time enabling WBS on oFono > > > but it looks like people are now trying to come with their own > > > solutions and complaining about lack of WBS is not really justified > > > since the combination of BlueZ + oFono has been in use by the car > > > industry for years but desktop folks has not been interested in a > > > proper HFP solution so instead we have modem manager, network manager, > > > etc, which doesn't even cover all desktop use cases properly as you > > > are experience first hand here. > > > > Apparently all people who are periodically writing me private emails are > > not interested in car industry, but are ordinary desktop / laptop users > > and ofono is not ready for these use cases and are not going to fix it. > > I guess that Aleksander and Andrew too are desktop / laptop users and > > not from car industry. > > Once you written and qualified your own HFP implementation we can > start talking about integrating it for desktop / laptop use, otherwise > the _only_ real option here is oFono, whether that requires a modem or > not is a different history, something that perhaps we should take on > to oFono to enable VoIP application to act as modems but that needs to > be discussed with oFono community. AuriStream does not need HFP, it is available also in HSP. So missing HFP should not be a blocker. Anyway, my HFP implementation is there: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288 https://github.com/pali/hsphfpd-prototype And people are already testing my HFP implementation with pulseaudio integration. So, we can continue at kernel level, as this is the missing part right now.
On 5/18/20 10:20 PM, Pali Rohár wrote> ... > AuriStream works also in HSP profile and I already implemented > negotiation for AuriStream codec for both HSP and HFP profiles. > > The only missing part is to unblock kernel to allow usage of AuriStream. > ... > AuriStream does not need HFP, it is available also in HSP. So missing > HFP should not be a blocker. > > Anyway, my HFP implementation is there: > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288 > https://github.com/pali/hsphfpd-prototype > > And people are already testing my HFP implementation with pulseaudio > integration. > > So, we can continue at kernel level, as this is the missing part right > now. Reading through this thread, it seems like Pali has alleviated all concerns regarding the patch. I would like to ask what still remains to be done in order to make this patch more acceptable? Best, Ujjwal
Hi Ujjwal, On Wed, May 27, 2020 at 5:19 AM Ujjwal Sharma <ryzokuken@igalia.com> wrote: > > On 5/18/20 10:20 PM, Pali Rohár wrote> ... > > AuriStream works also in HSP profile and I already implemented > > negotiation for AuriStream codec for both HSP and HFP profiles. > > > > The only missing part is to unblock kernel to allow usage of AuriStream. > > ... > > AuriStream does not need HFP, it is available also in HSP. So missing > > HFP should not be a blocker. > > > > Anyway, my HFP implementation is there: > > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288 > > https://github.com/pali/hsphfpd-prototype > > > > And people are already testing my HFP implementation with pulseaudio > > integration. > > > > So, we can continue at kernel level, as this is the missing part right > > now. > > Reading through this thread, it seems like Pali has alleviated all > concerns regarding the patch. I would like to ask what still remains to > be done in order to make this patch more acceptable? Testing is one thing but for production we would need a qualifyable solution, that said I wouldn't oppose to have the socket option behind a module options (runtime) or Kconfig (build-time) so people willing to run this code can do on their own.
Hi Luiz! Thanks for your response. On 5/27/20 9:18 PM, Luiz Augusto von Dentz wrote: > Hi Ujjwal, > ... > Testing is one thing but for production we would need a qualifyable > solution, that said I wouldn't oppose to have the socket option behind > a module options (runtime) or Kconfig (build-time) so people willing > to run this code can do on their own. 1. What do you think is lacking in this solution that would make it qualifyable for production? I believe there are multiple people in this thread including Pali who are willing to put in the extra effort. 2. I'd be happy with a runtime option which would allow me to test this as well. Cheers, Ujjwal
On Wednesday 27 May 2020 21:54:18 Ujjwal Sharma wrote: > Hi Luiz! > > Thanks for your response. > > On 5/27/20 9:18 PM, Luiz Augusto von Dentz wrote: > > Hi Ujjwal, > > ... > > Testing is one thing but for production we would need a qualifyable > > solution, that said I wouldn't oppose to have the socket option behind > > a module options (runtime) or Kconfig (build-time) so people willing > > to run this code can do on their own. > > 1. What do you think is lacking in this solution that would make it > qualifyable for production? I believe there are multiple people in this > thread including Pali who are willing to put in the extra effort. > > 2. I'd be happy with a runtime option which would allow me to test this > as well. Have I missed something? setsockopt() solution which I described in <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime option.
Hello Luiz, On Thu, Jun 04, 2020 at 10:43:43PM +0200, Pali Rohár wrote: > On Wednesday 27 May 2020 21:54:18 Ujjwal Sharma wrote: > > Hi Luiz! > > > > Thanks for your response. > > > > On 5/27/20 9:18 PM, Luiz Augusto von Dentz wrote: > > > Hi Ujjwal, > > > ... > > > Testing is one thing but for production we would need a qualifyable > > > solution, that said I wouldn't oppose to have the socket option behind > > > a module options (runtime) or Kconfig (build-time) so people willing > > > to run this code can do on their own. > > > > 1. What do you think is lacking in this solution that would make it > > qualifyable for production? I believe there are multiple people in this > > thread including Pali who are willing to put in the extra effort. > > > > 2. I'd be happy with a runtime option which would allow me to test this > > as well. > > Have I missed something? setsockopt() solution which I described in > <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime option. > Luiz: Please comment here.. what's missing from these patches? How can we get these merged? Pulseaudio support is pending this kernel support/patches.. Thanks a lot, -- Pasi
On Thursday 04 June 2020 22:43:43 Pali Rohár wrote: > On Wednesday 27 May 2020 21:54:18 Ujjwal Sharma wrote: > > Hi Luiz! > > > > Thanks for your response. > > > > On 5/27/20 9:18 PM, Luiz Augusto von Dentz wrote: > > > Hi Ujjwal, > > > ... > > > Testing is one thing but for production we would need a qualifyable > > > solution, that said I wouldn't oppose to have the socket option behind > > > a module options (runtime) or Kconfig (build-time) so people willing > > > to run this code can do on their own. > > > > 1. What do you think is lacking in this solution that would make it > > qualifyable for production? I believe there are multiple people in this > > thread including Pali who are willing to put in the extra effort. > > > > 2. I'd be happy with a runtime option which would allow me to test this > > as well. > > Have I missed something? setsockopt() solution which I described in > <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime option. PING (after 4 months)?
Am Dienstag, den 29.09.2020, 23:04 +0200 schrieb Pali Rohár: > On Thursday 04 June 2020 22:43:43 Pali Rohár wrote: > > On Wednesday 27 May 2020 21:54:18 Ujjwal Sharma wrote: > > > Hi Luiz! > > > > > > Thanks for your response. > > > > > > On 5/27/20 9:18 PM, Luiz Augusto von Dentz wrote: > > > > Hi Ujjwal, > > > > ... > > > > Testing is one thing but for production we would need a > > > > qualifyable > > > > solution, that said I wouldn't oppose to have the socket option > > > > behind > > > > a module options (runtime) or Kconfig (build-time) so people > > > > willing > > > > to run this code can do on their own. > > > > > > 1. What do you think is lacking in this solution that would make > > > it > > > qualifyable for production? I believe there are multiple people > > > in this > > > thread including Pali who are willing to put in the extra effort. > > > > > > 2. I'd be happy with a runtime option which would allow me to > > > test this > > > as well. > > > > Have I missed something? setsockopt() solution which I described in > > <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime > > option. > > PING (after 4 months)? Hello all, I'm currently (once again) trying to get different BT headsets working on Linux, with good audio quality also for telephony. It's unfortunately still the same issue: I can get good quality for playback only, but as soon as I start using HSP or HFP profiles to enable and use the headset's microphone, I will have poor audio quality only. Unfortunately this stops me (and I guess many other users) from being able to use any wireless headset on Linux desktop. On an Android phone the same headsets are working fine, also with the microphone enabled, with good audio quality. What can be done to finally make this work on Linux desktop? As far as I understand HFP profile with a supported codec has to be used, to get telephony with better quality. All the hard work Pali did for this seems to be the most promising solution for this right now, as far as I can tell. What can be done to get his patch merged? What is currently blocking this or what are the reasons / open issues why it can't be merged? I'm willing to support if I can! At least I can offer some of my time for manually installing and testing this, if it helps. I've also updated the patch already to let it compile successfully with newer kernel version (tried with linux58) and I can provide this updated version if it helps. (but I am not sure if everything works as it should) I hope this can be pushed forward. Would make me (and many other) users so happy to finally get wireless headphones working better! Thanks to all of you for your hard work!! (and I know, very often in your free time!) Best, Joschi
> I hope this can be pushed forward. Would make me (and many other) users > so happy to finally get wireless headphones working better! I agree. What is needed to push this forward? Thank you. Paul
Am Mittwoch, den 28.10.2020, 11:29 -0500 schrieb Paul Stejskal: > What can we do to get this published? > As far as I understand Pali is waiting for feedback for his updated suggestion from this email https://lore.kernel.org/linux-bluetooth/20191121224455.orhslaa6zdmlwe43@pali/ with this patch attached https://lore.kernel.org/linux-bluetooth/20191121224455.orhslaa6zdmlwe43@pali/1.2-sco.patch And as soon as this approach is confirmed I guess he could provide a new updated patch in the required format and updated to the latest mainline kernel version? @Pali: Not sure if I got it right. Maybe you can check yourself and confirm or correct me if I'm wrong. Thanks to all!
Am Mittwoch, den 28.10.2020, 21:25 +0100 schrieb Joschi 127: > Am Mittwoch, den 28.10.2020, 11:29 -0500 schrieb Paul Stejskal: > > What can we do to get this published? > > > > As far as I understand Pali is waiting for feedback for his updated > suggestion from this email > https://lore.kernel.org/linux-bluetooth/20191121224455.orhslaa6zdmlwe43@pali/ > > with this patch attached > https://lore.kernel.org/linux-bluetooth/20191121224455.orhslaa6zdmlwe43@pali/1.2-sco.patch > > > And as soon as this approach is confirmed I guess he could provide a > new updated patch in the required format and updated to the latest > mainline kernel version? > > @Pali: Not sure if I got it right. Maybe you can check yourself and > confirm or correct me if I'm wrong. > > Thanks to all! > > Hi all, sorry for pushing. I really think this would be so important for Linux desktop or laptop environments. What can we do to make progress on this? @Pali: Can you check if my summary above is correct? What has to be done to finalize this? Thanks very much to everyone! Joschi
On Tuesday 03 November 2020 13:10:50 Joschi 127 wrote: > @Pali: Can you check if my summary above is correct? What has to be > done to finalize this? Hello Joschi! The last update of proposed API (without implementation) with explanation is in email: https://lore.kernel.org/linux-bluetooth/20200419234937.4zozkqgpt557m3o6@pali/ What is needed is to review proposed API, approve it and then implement kernel code for this API.
Pali Rohár wrote: > Have I missed something? setsockopt() solution which I described in > <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime option. I think what Luiz meant was that there has to be a module option that enables the additional kernel code, for example modprobe bluetooth enable_voice_setup=1 This would enable us interested folk to test the changes, while they cannot blow up other peoples Bluetooth stack. At least that's the reasoning that I assume. The setsockopt() is a runtime option on the application side but doesn't "protect" the kernel. Content-wise, I understand Luiz' message as an approval of the general API you proposed, as long as it is not active by default. Best regards, Jan-Philipp
Hi Jan-Philipp, On Tue, Nov 3, 2020 at 4:43 AM Jan-Philipp Litza <janphilipp@litza.de> wrote: > > Pali Rohár wrote: > > Have I missed something? setsockopt() solution which I described in > > <20200419234937.4zozkqgpt557m3o6@pali> email is already runtime option. > > I think what Luiz meant was that there has to be a module option that > enables the additional kernel code, for example > > modprobe bluetooth enable_voice_setup=1 > > This would enable us interested folk to test the changes, while they > cannot blow up other peoples Bluetooth stack. At least that's the > reasoning that I assume. > > The setsockopt() is a runtime option on the application side but doesn't > "protect" the kernel. > > Content-wise, I understand Luiz' message as an approval of the general > API you proposed, as long as it is not active by default. Yes, in fact we are trending to introduce experimental interfaces for most of our new features so we can polish them and users can test with either build time option or runtime option like you mentioned above, this should balance the stabilization of new features with power users that do want to use them even though there are not marked as stable.
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h index fabee6db0abb..f1f482bdf526 100644 --- a/include/net/bluetooth/bluetooth.h +++ b/include/net/bluetooth/bluetooth.h @@ -122,6 +122,37 @@ struct bt_voice { #define BT_SNDMTU 12 #define BT_RCVMTU 13 +#define BT_VOICE_SETUP 14 + +#define BT_VOICE_PKT_TYPE_CAP_SCO BIT(0) +#define BT_VOICE_PKT_TYPE_CAP_ESCO BIT(1) +struct bt_voice_pkt_type { + __u8 capability; /* bitmask of BT_VOICE_PKT_TYPE_CAP_* */ + __u8 retrans_effort; + __u16 pkt_type; + __u16 max_latency; +}; +struct bt_voice_setup { + __u32 tx_bandwidth; + __u32 rx_bandwidth; + __u16 tx_codec_frame_size; + __u16 rx_codec_frame_size; + __u8 tx_coding_format[5]; + __u8 rx_coding_format[5]; + __u8 input_coding_format[5]; + __u8 output_coding_format[5]; + __u16 input_coded_data_size; + __u16 output_coded_data_size; + __u8 input_pcm_data_format; + __u8 output_pcm_data_format; + __u8 input_pcm_msb_position; + __u8 output_pcm_msb_position; + __u32 input_bandwidth; + __u32 output_bandwidth; + __u32 pkt_types_count; + struct bt_voice_pkt_type pkt_types[]; +}; + __printf(1, 2) void bt_info(const char *fmt, ...); __printf(1, 2)
Hello! I'm sending next attempt for userspace <--> kernel API for specifying connection settings of SCO socket. I was thinking more about it and I was able to remove some members from struct bt_voice_setup which are not needed for Linux SCO sockets (e.g. specifying different routing then over HCI). Here is this API: Structure specify settings for exactly one codec. Meaning of those members is same as for Enhanced Setup Synchronous Connection HCI command. Let me a bit explain it: Members tx_bandwidth, rx_bandwidth, tx_codec_frame_size, rx_codec_frame_size, tx_coding_format and rx_coding_format specify AIR codec and all of them are needed to correctly describe codec used by bluetooth adapter to transmit data over the air. All of these members are also part of Enhanced Setup Synchronous Connection command and application which want to use vendor codec needs to control of all them. Members input_coding_format, output_coding_format, input_coded_data_size, output_coded_data_size, input_bandwidth and output_bandwidth describe LOCAL codec, format of audio data which is passed by application to the bluetooth adapter. It does not have to be same as AIR codec and in this case bluetooth adapter is doing HW encoding/decoding. When coding_format is PCM then additional parameters for PCM format needs to be specified, more exactly they are in members: input_pcm_data_format, output_pcm_data_format, input_pcm_msb_position and output_pcm_msb_position. For modern audio applications is is required to control all of these PCM parameters as audio application does not have to reencode everything to one format (e.g. 8Hz/s16le), but let bluetooth adapter to do reencoding at HW level. The last pkt_types[] array (with pkt_types_count items) defines what type bluetooth packets and SCO/eSCO mode can be used with particular codec. So all members of that structure are needed for userspace audio applications (e.g. pulseaudio) and without them it is not possible implement custom vendor SCO codecs which are already used in bluetooth headsets. Also without them it is not possible to use HW encoders in bluetooth chip, e.g. mSBC and applications are forced to use in-software encoding/decoding which may be slow or increase latency or power usage. And here are some example how to use it: SCO socket that would accept 16kHz PCM s16le data and bluetooth chip would encode it to mSBC over the air. #define HCI_CODING_FORMAT_PCM 0x04 #define HCI_CODING_FORMAT_MSBC 0x05 #define HCI_PCM_DATA_FORMAT_2COMP 0x02 static const struct bt_voice_setup voice_setup = { .tx_bandwidth = 8000, .rx_bandwidth = 8000, .tx_codec_frame_size = 60, .rx_codec_frame_size = 60, .tx_coding_format = { HCI_CODING_FORMAT_MSBC }, .rx_coding_format = { HCI_CODING_FORMAT_MSBC }, .input_coding_format = { HCI_CODING_FORMAT_PCM }, .output_coding_format = { HCI_CODING_FORMAT_PCM }, .input_coded_data_size = 16, .output_coded_data_size = 16, .input_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, .output_pcm_data_format = HCI_PCM_DATA_FORMAT_2COMP, .input_pcm_msb_position = 0, .output_pcm_msb_position = 0, .input_bandwidth = 32000, .output_bandwidth = 32000, .pkt_types_count = 2, .pkt_types = { { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d }, /* T2 */ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, EDR_ESCO_MASK | ESCO_EV3, 0x0008 }, /* T1 */ }, }; int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); bind(fd, ...); setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); connect(fd, ...); SCO socket that would accept AuriStream codec from application and tell bluetooth chip to pass-throu as is over the air: #define HCI_CODING_FORMAT_TRANSPARENT 0x03 static const struct bt_voice_setup voice_setup = { .tx_bandwidth = 4000, .rx_bandwidth = 4000, .tx_codec_frame_size = 60, .rx_codec_frame_size = 60, .tx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, .rx_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, .input_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, .output_coding_format = { HCI_CODING_FORMAT_TRANSPARENT }, .input_coded_data_size = 8, .output_coded_data_size = 8, .input_pcm_data_format = 0, .output_pcm_data_format = 0, .input_pcm_msb_position = 0, .output_pcm_msb_position = 0, .input_bandwidth = 4000, .output_bandwidth = 4000, .pkt_types_count = 1, .pkt_types = { { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x02, 0x003F, 16 }, }, }; int fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); bind(fd, ...); setsockopt(fd, SOL_BLUETOOTH, BT_VOICE_SETUP, &voice_setup, sizeof(voice_setup)); connect(fd, ...); That API is designed for Enhanced Setup Synchronous Connection HCI command, but can also be used by plain Setup Synchronous Connection HCI command. Plain version has just reduced set of features and basically instead of AIR codec members and LOCAL codec members use just one u16 member voice_setting, which is just subset of all those possible Enhanced settings and can be generated from them. E.g. transparent coding format is encoded in voice_setting as 0x0003, usage of CVSD HW encoder from pcm_s16le_8kHz as 0x0060, but e.g. usage of mSBC HW encoder is not possible to specify. Please let me know what do you think about it. Thanks