Ccing more people...
do you have idea why for custom SCO HFP codec is needed to change
Transmit and Receive bandwidth in HCI Setup Synchronous Connection
packet?
And how to expose API for userspace applications so they can change
hardcoded kernel bandwidth? Why is there value 8000?
Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
socket for AuriStream codec in HFP profile.
On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> Hello,
>
> I found out that more bluetooth headsets supports AuriStream codec in
> bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> ADPCM variant with better quality as default CVSD codec.
>
> Headset announce their support by sending command AT+CSRSF, in sixth
> number with first or second bit set (counted from zero). E.g.:
>
> AT+CSRSF=0,0,0,0,0,7
>
> Codec is then selected by host with sending:
>
> +CSRFN: (6,4)
> OK
>
> And answer from headset is acknowledged by another:
>
> OK
>
>
> Problem is that on Linux after issuing these AT commands I cannot longer
> connect to SCO socket. connect() fails with Protocol Error.
>
> And in btmon is following error:
>
> > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
>
>
> In some CSR SKD is example how to activate it and there is code which
> seems to sets following HCI connection parameters:
>
> syncPktTypes = 0x003F
> bandwidth = 4000
> max_latency = 16
> voice_settings = 0x63
> retx_effort = 2
>
> I figured out that voice_settings can be configured via setsockopt()
> SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> accept only two whitelisted values: 0x0003 and 0x0060.
>
> So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
>
> In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> to Transparent, but I still got same "Invalid LMP Parameters" error.
>
> I tried to remove that whilelist from BT_VOICE option via patch below:
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index 9a580999ca57..06db91de4f23 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> else
> type = SCO_LINK;
>
> - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> err = -EOPNOTSUPP;
> goto done;
> @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> break;
> }
>
> - /* Explicitly check for these values */
> - if (voice.setting != BT_VOICE_TRANSPARENT &&
> - voice.setting != BT_VOICE_CVSD_16BIT) {
> - err = -EINVAL;
> - break;
> - }
> -
> sco_pi(sk)->setting = voice.setting;
> break;
>
>
> Btmon now really showed Settings as 0x63, but still did not worked.
> Again exactly same HCI error.
>
> Next I tried hacking linux kernel to customize packet type and max
> latency. But even I changed these values I still got that HCI error.
>
> After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> above connection parameters), connect() syscall for that SCO socket
> succeeded and I started getting voice microphone data on that socket.
>
> And it worked also with voice settings 0x0003 with active in-kernel
> whitelist.
>
> Patch which is needed is following: Change bandwidth to 4000:
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index bd4978ce8c45..2dd4d0412971 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
>
> cp.handle = cpu_to_le16(handle);
>
> - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> + cp.tx_bandwidth = cpu_to_le32(4000);
> + cp.rx_bandwidth = cpu_to_le32(4000);
> cp.voice_setting = cpu_to_le16(conn->setting);
>
> switch (conn->setting & SCO_AIRMODE_MASK) {
>
> I have really no idea what it does with headset. But without this patch
> I'm not able to switch HSP codec from CVSD to AuriStream.
>
> Is somebody able to explain how above change can allow opening SCO
> socket?
>
> Because without it I'm not able to activate AuriStream codec, could you
> consider allowing userspace (via some setsockoptň to change bandwidth?
> Because now it is hardcoded in kernel source code.
>
> For more details here is btmon output with default bandwidth which is
> failing:
>
> $ sudo ./monitor/btmon
> Bluetooth monitor ver 5.50
> = Note: Linux version 4.9.0-9-amd64 (x86_64)
> = Note: Bluetooth subsystem version 2.22
> = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> = Open Index: XX:XX:XX:XX:XX:XX
> = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> @ MGMT Open: bluetoothd (privileged) version 1.14
> @ MGMT Open: btmon (privileged) version 1.14
> < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> Handle: 34
> Transmit bandwidth: 8000
> Receive bandwidth: 8000
> Max latency: 13
> Setting: 0x0003
> Input Coding: Linear
> Input Data Format: 1's complement
> Input Sample Size: 8-bit
> # of bits padding at MSB: 0
> Air Coding Format: Transparent Data
> Retransmission effort: Optimize for link quality (0x02)
> Packet type: 0x0380
> 3-EV3 may not be used
> 2-EV5 may not be used
> 3-EV5 may not be used
> > HCI Event: Command Status (0x0f) plen 4
> Setup Synchronous Connection (0x01|0x0028) ncmd 1
> Status: Success (0x00)
> > HCI Event: Max Slots Change (0x1b) plen 3
> Handle: 34
> Max slots: 1
> > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> Handle: 34
> Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> Link type: eSCO (0x02)
> Transmission interval: 0x00
> Retransmission window: 0x00
> RX packet length: 0
> TX packet length: 0
> Air mode: u-law log (0x00)
> > HCI Event: Max Slots Change (0x1b) plen 3
> Handle: 34
> Max slots: 5
>
> And here is btmon output with above kernel patch which changes bandwidth to 4000:
>
> $ sudo ./monitor/btmon
> Bluetooth monitor ver 5.50
> = Note: Linux version 4.9.0-9-amd64 (x86_64)
> = Note: Bluetooth subsystem version 2.22
> = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> = Open Index: XX:XX:XX:XX:XX:XX
> = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> @ MGMT Open: bluetoothd (privileged) version 1.14
> @ MGMT Open: btmon (privileged) version 1.14
> < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> Handle: 34
> Transmit bandwidth: 4000
> Receive bandwidth: 4000
> Max latency: 13
> Setting: 0x0003
> Input Coding: Linear
> Input Data Format: 1's complement
> Input Sample Size: 8-bit
> # of bits padding at MSB: 0
> Air Coding Format: Transparent Data
> Retransmission effort: Optimize for link quality (0x02)
> Packet type: 0x0380
> 3-EV3 may not be used
> 2-EV5 may not be used
> 3-EV5 may not be used
> > HCI Event: Command Status (0x0f) plen 4
> Setup Synchronous Connection (0x01|0x0028) ncmd 1
> Status: Success (0x00)
> > HCI Event: Max Slots Change (0x1b) plen 3
> Handle: 34
> Max slots: 1
> > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> Status: Success (0x00)
> Handle: 38
> Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> Link type: eSCO (0x02)
> Transmission interval: 0x10
> Retransmission window: 0x02
> RX packet length: 40
> TX packet length: 40
> Air mode: Transparent (0x03)
> < SCO Data TX: Handle 38 flags 0x00 dlen 48
> < ACL Data TX: Handle 34 flags 0x00 dlen 18
> Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> Num handles: 1
> Handle: 34
> Count: 1
> > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > SCO Data RX: Handle 38 flags 0x00 dlen 24
> < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > HCI Event: Max Slots Change (0x1b) plen 3
> Handle: 34
> Max slots: 5
>
> ... and SCO data are coming on SCO socket.
>
--
Pali Rohár
[email protected]
Ping, can you comment anything related to hardcoded bandwidth?
I would really like to take next step how to expose API for changing
bandwidth as linux kernel currently does not allow to receive and
transmit voice encoded by AuriStream codec.
On Monday 06 May 2019 17:16:51 Pali Rohár wrote:
> Ccing more people...
>
> do you have idea why for custom SCO HFP codec is needed to change
> Transmit and Receive bandwidth in HCI Setup Synchronous Connection
> packet?
>
> And how to expose API for userspace applications so they can change
> hardcoded kernel bandwidth? Why is there value 8000?
>
> Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
> socket for AuriStream codec in HFP profile.
>
> On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> > Hello,
> >
> > I found out that more bluetooth headsets supports AuriStream codec in
> > bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> > ADPCM variant with better quality as default CVSD codec.
> >
> > Headset announce their support by sending command AT+CSRSF, in sixth
> > number with first or second bit set (counted from zero). E.g.:
> >
> > AT+CSRSF=0,0,0,0,0,7
> >
> > Codec is then selected by host with sending:
> >
> > +CSRFN: (6,4)
> > OK
> >
> > And answer from headset is acknowledged by another:
> >
> > OK
> >
> >
> > Problem is that on Linux after issuing these AT commands I cannot longer
> > connect to SCO socket. connect() fails with Protocol Error.
> >
> > And in btmon is following error:
> >
> > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> >
> >
> > In some CSR SKD is example how to activate it and there is code which
> > seems to sets following HCI connection parameters:
> >
> > syncPktTypes = 0x003F
> > bandwidth = 4000
> > max_latency = 16
> > voice_settings = 0x63
> > retx_effort = 2
> >
> > I figured out that voice_settings can be configured via setsockopt()
> > SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> > accept only two whitelisted values: 0x0003 and 0x0060.
> >
> > So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
> >
> > In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> > to Transparent, but I still got same "Invalid LMP Parameters" error.
> >
> > I tried to remove that whilelist from BT_VOICE option via patch below:
> >
> > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > index 9a580999ca57..06db91de4f23 100644
> > --- a/net/bluetooth/sco.c
> > +++ b/net/bluetooth/sco.c
> > @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> > else
> > type = SCO_LINK;
> >
> > - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> > + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> > (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> > err = -EOPNOTSUPP;
> > goto done;
> > @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> > break;
> > }
> >
> > - /* Explicitly check for these values */
> > - if (voice.setting != BT_VOICE_TRANSPARENT &&
> > - voice.setting != BT_VOICE_CVSD_16BIT) {
> > - err = -EINVAL;
> > - break;
> > - }
> > -
> > sco_pi(sk)->setting = voice.setting;
> > break;
> >
> >
> > Btmon now really showed Settings as 0x63, but still did not worked.
> > Again exactly same HCI error.
> >
> > Next I tried hacking linux kernel to customize packet type and max
> > latency. But even I changed these values I still got that HCI error.
> >
> > After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> > above connection parameters), connect() syscall for that SCO socket
> > succeeded and I started getting voice microphone data on that socket.
> >
> > And it worked also with voice settings 0x0003 with active in-kernel
> > whitelist.
> >
> > Patch which is needed is following: Change bandwidth to 4000:
> >
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index bd4978ce8c45..2dd4d0412971 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
> >
> > cp.handle = cpu_to_le16(handle);
> >
> > - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> > - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> > + cp.tx_bandwidth = cpu_to_le32(4000);
> > + cp.rx_bandwidth = cpu_to_le32(4000);
> > cp.voice_setting = cpu_to_le16(conn->setting);
> >
> > switch (conn->setting & SCO_AIRMODE_MASK) {
> >
> > I have really no idea what it does with headset. But without this patch
> > I'm not able to switch HSP codec from CVSD to AuriStream.
> >
> > Is somebody able to explain how above change can allow opening SCO
> > socket?
> >
> > Because without it I'm not able to activate AuriStream codec, could you
> > consider allowing userspace (via some setsockoptň to change bandwidth?
> > Because now it is hardcoded in kernel source code.
> >
> > For more details here is btmon output with default bandwidth which is
> > failing:
> >
> > $ sudo ./monitor/btmon
> > Bluetooth monitor ver 5.50
> > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > = Note: Bluetooth subsystem version 2.22
> > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > = Open Index: XX:XX:XX:XX:XX:XX
> > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > @ MGMT Open: bluetoothd (privileged) version 1.14
> > @ MGMT Open: btmon (privileged) version 1.14
> > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > Handle: 34
> > Transmit bandwidth: 8000
> > Receive bandwidth: 8000
> > Max latency: 13
> > Setting: 0x0003
> > Input Coding: Linear
> > Input Data Format: 1's complement
> > Input Sample Size: 8-bit
> > # of bits padding at MSB: 0
> > Air Coding Format: Transparent Data
> > Retransmission effort: Optimize for link quality (0x02)
> > Packet type: 0x0380
> > 3-EV3 may not be used
> > 2-EV5 may not be used
> > 3-EV5 may not be used
> > > HCI Event: Command Status (0x0f) plen 4
> > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > Status: Success (0x00)
> > > HCI Event: Max Slots Change (0x1b) plen 3
> > Handle: 34
> > Max slots: 1
> > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > Handle: 34
> > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > Link type: eSCO (0x02)
> > Transmission interval: 0x00
> > Retransmission window: 0x00
> > RX packet length: 0
> > TX packet length: 0
> > Air mode: u-law log (0x00)
> > > HCI Event: Max Slots Change (0x1b) plen 3
> > Handle: 34
> > Max slots: 5
> >
> > And here is btmon output with above kernel patch which changes bandwidth to 4000:
> >
> > $ sudo ./monitor/btmon
> > Bluetooth monitor ver 5.50
> > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > = Note: Bluetooth subsystem version 2.22
> > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > = Open Index: XX:XX:XX:XX:XX:XX
> > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > @ MGMT Open: bluetoothd (privileged) version 1.14
> > @ MGMT Open: btmon (privileged) version 1.14
> > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > Handle: 34
> > Transmit bandwidth: 4000
> > Receive bandwidth: 4000
> > Max latency: 13
> > Setting: 0x0003
> > Input Coding: Linear
> > Input Data Format: 1's complement
> > Input Sample Size: 8-bit
> > # of bits padding at MSB: 0
> > Air Coding Format: Transparent Data
> > Retransmission effort: Optimize for link quality (0x02)
> > Packet type: 0x0380
> > 3-EV3 may not be used
> > 2-EV5 may not be used
> > 3-EV5 may not be used
> > > HCI Event: Command Status (0x0f) plen 4
> > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > Status: Success (0x00)
> > > HCI Event: Max Slots Change (0x1b) plen 3
> > Handle: 34
> > Max slots: 1
> > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > Status: Success (0x00)
> > Handle: 38
> > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > Link type: eSCO (0x02)
> > Transmission interval: 0x10
> > Retransmission window: 0x02
> > RX packet length: 40
> > TX packet length: 40
> > Air mode: Transparent (0x03)
> > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > < ACL Data TX: Handle 34 flags 0x00 dlen 18
> > Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> > 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > > HCI Event: Number of Completed Packets (0x13) plen 5
> > Num handles: 1
> > Handle: 34
> > Count: 1
> > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > HCI Event: Max Slots Change (0x1b) plen 3
> > Handle: 34
> > Max slots: 5
> >
> > ... and SCO data are coming on SCO socket.
> >
>
--
Pali Rohár
[email protected]
Hi Pali,
On Thu, May 16, 2019 at 9:34 PM Pali Rohár <[email protected]> wrote:
>
> Ping, can you comment anything related to hardcoded bandwidth?
>
> I would really like to take next step how to expose API for changing
> bandwidth as linux kernel currently does not allow to receive and
> transmit voice encoded by AuriStream codec.
Didn't even know such codec existed, anyway that is not using the
standard AT commands so it is kind hard to figure out how to set it up
properly, to be honest, I would rather see WBS implementation finally
reach PA before we start digging into this.
> On Monday 06 May 2019 17:16:51 Pali Rohár wrote:
> > Ccing more people...
> >
> > do you have idea why for custom SCO HFP codec is needed to change
> > Transmit and Receive bandwidth in HCI Setup Synchronous Connection
> > packet?
> >
> > And how to expose API for userspace applications so they can change
> > hardcoded kernel bandwidth? Why is there value 8000?
> >
> > Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
> > socket for AuriStream codec in HFP profile.
> >
> > On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> > > Hello,
> > >
> > > I found out that more bluetooth headsets supports AuriStream codec in
> > > bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> > > ADPCM variant with better quality as default CVSD codec.
> > >
> > > Headset announce their support by sending command AT+CSRSF, in sixth
> > > number with first or second bit set (counted from zero). E.g.:
> > >
> > > AT+CSRSF=0,0,0,0,0,7
> > >
> > > Codec is then selected by host with sending:
> > >
> > > +CSRFN: (6,4)
> > > OK
> > >
> > > And answer from headset is acknowledged by another:
> > >
> > > OK
> > >
> > >
> > > Problem is that on Linux after issuing these AT commands I cannot longer
> > > connect to SCO socket. connect() fails with Protocol Error.
> > >
> > > And in btmon is following error:
> > >
> > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > >
> > >
> > > In some CSR SKD is example how to activate it and there is code which
> > > seems to sets following HCI connection parameters:
> > >
> > > syncPktTypes = 0x003F
> > > bandwidth = 4000
> > > max_latency = 16
> > > voice_settings = 0x63
> > > retx_effort = 2
> > >
> > > I figured out that voice_settings can be configured via setsockopt()
> > > SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> > > accept only two whitelisted values: 0x0003 and 0x0060.
> > >
> > > So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
> > >
> > > In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> > > to Transparent, but I still got same "Invalid LMP Parameters" error.
> > >
> > > I tried to remove that whilelist from BT_VOICE option via patch below:
> > >
> > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > index 9a580999ca57..06db91de4f23 100644
> > > --- a/net/bluetooth/sco.c
> > > +++ b/net/bluetooth/sco.c
> > > @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> > > else
> > > type = SCO_LINK;
> > >
> > > - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> > > + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> > > (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> > > err = -EOPNOTSUPP;
> > > goto done;
> > > @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> > > break;
> > > }
> > >
> > > - /* Explicitly check for these values */
> > > - if (voice.setting != BT_VOICE_TRANSPARENT &&
> > > - voice.setting != BT_VOICE_CVSD_16BIT) {
> > > - err = -EINVAL;
> > > - break;
> > > - }
> > > -
> > > sco_pi(sk)->setting = voice.setting;
> > > break;
> > >
> > >
> > > Btmon now really showed Settings as 0x63, but still did not worked.
> > > Again exactly same HCI error.
> > >
> > > Next I tried hacking linux kernel to customize packet type and max
> > > latency. But even I changed these values I still got that HCI error.
> > >
> > > After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> > > above connection parameters), connect() syscall for that SCO socket
> > > succeeded and I started getting voice microphone data on that socket.
> > >
> > > And it worked also with voice settings 0x0003 with active in-kernel
> > > whitelist.
> > >
> > > Patch which is needed is following: Change bandwidth to 4000:
> > >
> > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > > index bd4978ce8c45..2dd4d0412971 100644
> > > --- a/net/bluetooth/hci_conn.c
> > > +++ b/net/bluetooth/hci_conn.c
> > > @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
> > >
> > > cp.handle = cpu_to_le16(handle);
> > >
> > > - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> > > - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> > > + cp.tx_bandwidth = cpu_to_le32(4000);
> > > + cp.rx_bandwidth = cpu_to_le32(4000);
> > > cp.voice_setting = cpu_to_le16(conn->setting);
> > >
> > > switch (conn->setting & SCO_AIRMODE_MASK) {
> > >
> > > I have really no idea what it does with headset. But without this patch
> > > I'm not able to switch HSP codec from CVSD to AuriStream.
> > >
> > > Is somebody able to explain how above change can allow opening SCO
> > > socket?
> > >
> > > Because without it I'm not able to activate AuriStream codec, could you
> > > consider allowing userspace (via some setsockoptň to change bandwidth?
> > > Because now it is hardcoded in kernel source code.
> > >
> > > For more details here is btmon output with default bandwidth which is
> > > failing:
> > >
> > > $ sudo ./monitor/btmon
> > > Bluetooth monitor ver 5.50
> > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > = Note: Bluetooth subsystem version 2.22
> > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > = Open Index: XX:XX:XX:XX:XX:XX
> > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > @ MGMT Open: btmon (privileged) version 1.14
> > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > Handle: 34
> > > Transmit bandwidth: 8000
> > > Receive bandwidth: 8000
> > > Max latency: 13
> > > Setting: 0x0003
> > > Input Coding: Linear
> > > Input Data Format: 1's complement
> > > Input Sample Size: 8-bit
> > > # of bits padding at MSB: 0
> > > Air Coding Format: Transparent Data
> > > Retransmission effort: Optimize for link quality (0x02)
> > > Packet type: 0x0380
> > > 3-EV3 may not be used
> > > 2-EV5 may not be used
> > > 3-EV5 may not be used
> > > > HCI Event: Command Status (0x0f) plen 4
> > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > Status: Success (0x00)
> > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > Handle: 34
> > > Max slots: 1
> > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > Handle: 34
> > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > Link type: eSCO (0x02)
> > > Transmission interval: 0x00
> > > Retransmission window: 0x00
> > > RX packet length: 0
> > > TX packet length: 0
> > > Air mode: u-law log (0x00)
> > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > Handle: 34
> > > Max slots: 5
> > >
> > > And here is btmon output with above kernel patch which changes bandwidth to 4000:
> > >
> > > $ sudo ./monitor/btmon
> > > Bluetooth monitor ver 5.50
> > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > = Note: Bluetooth subsystem version 2.22
> > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > = Open Index: XX:XX:XX:XX:XX:XX
> > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > @ MGMT Open: btmon (privileged) version 1.14
> > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > Handle: 34
> > > Transmit bandwidth: 4000
> > > Receive bandwidth: 4000
> > > Max latency: 13
> > > Setting: 0x0003
> > > Input Coding: Linear
> > > Input Data Format: 1's complement
> > > Input Sample Size: 8-bit
> > > # of bits padding at MSB: 0
> > > Air Coding Format: Transparent Data
> > > Retransmission effort: Optimize for link quality (0x02)
> > > Packet type: 0x0380
> > > 3-EV3 may not be used
> > > 2-EV5 may not be used
> > > 3-EV5 may not be used
> > > > HCI Event: Command Status (0x0f) plen 4
> > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > Status: Success (0x00)
> > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > Handle: 34
> > > Max slots: 1
> > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > Status: Success (0x00)
> > > Handle: 38
> > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > Link type: eSCO (0x02)
> > > Transmission interval: 0x10
> > > Retransmission window: 0x02
> > > RX packet length: 40
> > > TX packet length: 40
> > > Air mode: Transparent (0x03)
> > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > < ACL Data TX: Handle 34 flags 0x00 dlen 18
> > > Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> > > 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > > > HCI Event: Number of Completed Packets (0x13) plen 5
> > > Num handles: 1
> > > Handle: 34
> > > Count: 1
> > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > Handle: 34
> > > Max slots: 5
> > >
> > > ... and SCO data are coming on SCO socket.
> > >
> >
>
> --
> Pali Rohár
> [email protected]
--
Luiz Augusto von Dentz
On Sunday 19 May 2019 11:16:00 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Thu, May 16, 2019 at 9:34 PM Pali Rohár <[email protected]> wrote:
> >
> > Ping, can you comment anything related to hardcoded bandwidth?
> >
> > I would really like to take next step how to expose API for changing
> > bandwidth as linux kernel currently does not allow to receive and
> > transmit voice encoded by AuriStream codec.
>
> Didn't even know such codec existed, anyway that is not using the
> standard AT commands so it is kind hard to figure out how to set it up
> properly,
Yes, AT+CSRSF is not standard AT command, but CSR extension. Also there
are e.g. more headsets which support Apple extensions to AT commands...
And Apple has public documentation for it.
> to be honest, I would rather see WBS implementation finally
> reach PA before we start digging into this.
First I want to finish improving A2DP codec support in pulseaudio. Later
I can look at HSP/HFP profiles. Ideally it should have modular/plugin
extensible design. So the aim is that adding new codec would be very
simple, without need to hack something related to mSBC/WBC, AuriStream
or any other codec.
But for AuriStream I need to set custom SCO parameters as described
below and currently kernel does not support it. This is why I'm asking
how kernel can export for userspace configuration of SCO parameters...
> > On Monday 06 May 2019 17:16:51 Pali Rohár wrote:
> > > Ccing more people...
> > >
> > > do you have idea why for custom SCO HFP codec is needed to change
> > > Transmit and Receive bandwidth in HCI Setup Synchronous Connection
> > > packet?
> > >
> > > And how to expose API for userspace applications so they can change
> > > hardcoded kernel bandwidth? Why is there value 8000?
> > >
> > > Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
> > > socket for AuriStream codec in HFP profile.
> > >
> > > On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> > > > Hello,
> > > >
> > > > I found out that more bluetooth headsets supports AuriStream codec in
> > > > bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> > > > ADPCM variant with better quality as default CVSD codec.
> > > >
> > > > Headset announce their support by sending command AT+CSRSF, in sixth
> > > > number with first or second bit set (counted from zero). E.g.:
> > > >
> > > > AT+CSRSF=0,0,0,0,0,7
> > > >
> > > > Codec is then selected by host with sending:
> > > >
> > > > +CSRFN: (6,4)
> > > > OK
> > > >
> > > > And answer from headset is acknowledged by another:
> > > >
> > > > OK
> > > >
> > > >
> > > > Problem is that on Linux after issuing these AT commands I cannot longer
> > > > connect to SCO socket. connect() fails with Protocol Error.
> > > >
> > > > And in btmon is following error:
> > > >
> > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > >
> > > >
> > > > In some CSR SKD is example how to activate it and there is code which
> > > > seems to sets following HCI connection parameters:
> > > >
> > > > syncPktTypes = 0x003F
> > > > bandwidth = 4000
> > > > max_latency = 16
> > > > voice_settings = 0x63
> > > > retx_effort = 2
> > > >
> > > > I figured out that voice_settings can be configured via setsockopt()
> > > > SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> > > > accept only two whitelisted values: 0x0003 and 0x0060.
> > > >
> > > > So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
> > > >
> > > > In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> > > > to Transparent, but I still got same "Invalid LMP Parameters" error.
> > > >
> > > > I tried to remove that whilelist from BT_VOICE option via patch below:
> > > >
> > > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > > index 9a580999ca57..06db91de4f23 100644
> > > > --- a/net/bluetooth/sco.c
> > > > +++ b/net/bluetooth/sco.c
> > > > @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> > > > else
> > > > type = SCO_LINK;
> > > >
> > > > - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> > > > + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> > > > (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> > > > err = -EOPNOTSUPP;
> > > > goto done;
> > > > @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> > > > break;
> > > > }
> > > >
> > > > - /* Explicitly check for these values */
> > > > - if (voice.setting != BT_VOICE_TRANSPARENT &&
> > > > - voice.setting != BT_VOICE_CVSD_16BIT) {
> > > > - err = -EINVAL;
> > > > - break;
> > > > - }
> > > > -
> > > > sco_pi(sk)->setting = voice.setting;
> > > > break;
> > > >
> > > >
> > > > Btmon now really showed Settings as 0x63, but still did not worked.
> > > > Again exactly same HCI error.
> > > >
> > > > Next I tried hacking linux kernel to customize packet type and max
> > > > latency. But even I changed these values I still got that HCI error.
> > > >
> > > > After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> > > > above connection parameters), connect() syscall for that SCO socket
> > > > succeeded and I started getting voice microphone data on that socket.
> > > >
> > > > And it worked also with voice settings 0x0003 with active in-kernel
> > > > whitelist.
> > > >
> > > > Patch which is needed is following: Change bandwidth to 4000:
> > > >
> > > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > > > index bd4978ce8c45..2dd4d0412971 100644
> > > > --- a/net/bluetooth/hci_conn.c
> > > > +++ b/net/bluetooth/hci_conn.c
> > > > @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
> > > >
> > > > cp.handle = cpu_to_le16(handle);
> > > >
> > > > - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> > > > - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> > > > + cp.tx_bandwidth = cpu_to_le32(4000);
> > > > + cp.rx_bandwidth = cpu_to_le32(4000);
> > > > cp.voice_setting = cpu_to_le16(conn->setting);
> > > >
> > > > switch (conn->setting & SCO_AIRMODE_MASK) {
> > > >
> > > > I have really no idea what it does with headset. But without this patch
> > > > I'm not able to switch HSP codec from CVSD to AuriStream.
> > > >
> > > > Is somebody able to explain how above change can allow opening SCO
> > > > socket?
> > > >
> > > > Because without it I'm not able to activate AuriStream codec, could you
> > > > consider allowing userspace (via some setsockoptň to change bandwidth?
> > > > Because now it is hardcoded in kernel source code.
> > > >
> > > > For more details here is btmon output with default bandwidth which is
> > > > failing:
> > > >
> > > > $ sudo ./monitor/btmon
> > > > Bluetooth monitor ver 5.50
> > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > = Note: Bluetooth subsystem version 2.22
> > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > Handle: 34
> > > > Transmit bandwidth: 8000
> > > > Receive bandwidth: 8000
> > > > Max latency: 13
> > > > Setting: 0x0003
> > > > Input Coding: Linear
> > > > Input Data Format: 1's complement
> > > > Input Sample Size: 8-bit
> > > > # of bits padding at MSB: 0
> > > > Air Coding Format: Transparent Data
> > > > Retransmission effort: Optimize for link quality (0x02)
> > > > Packet type: 0x0380
> > > > 3-EV3 may not be used
> > > > 2-EV5 may not be used
> > > > 3-EV5 may not be used
> > > > > HCI Event: Command Status (0x0f) plen 4
> > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > Status: Success (0x00)
> > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > Handle: 34
> > > > Max slots: 1
> > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > > Handle: 34
> > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > Link type: eSCO (0x02)
> > > > Transmission interval: 0x00
> > > > Retransmission window: 0x00
> > > > RX packet length: 0
> > > > TX packet length: 0
> > > > Air mode: u-law log (0x00)
> > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > Handle: 34
> > > > Max slots: 5
> > > >
> > > > And here is btmon output with above kernel patch which changes bandwidth to 4000:
> > > >
> > > > $ sudo ./monitor/btmon
> > > > Bluetooth monitor ver 5.50
> > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > = Note: Bluetooth subsystem version 2.22
> > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > Handle: 34
> > > > Transmit bandwidth: 4000
> > > > Receive bandwidth: 4000
> > > > Max latency: 13
> > > > Setting: 0x0003
> > > > Input Coding: Linear
> > > > Input Data Format: 1's complement
> > > > Input Sample Size: 8-bit
> > > > # of bits padding at MSB: 0
> > > > Air Coding Format: Transparent Data
> > > > Retransmission effort: Optimize for link quality (0x02)
> > > > Packet type: 0x0380
> > > > 3-EV3 may not be used
> > > > 2-EV5 may not be used
> > > > 3-EV5 may not be used
> > > > > HCI Event: Command Status (0x0f) plen 4
> > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > Status: Success (0x00)
> > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > Handle: 34
> > > > Max slots: 1
> > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > Status: Success (0x00)
> > > > Handle: 38
> > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > Link type: eSCO (0x02)
> > > > Transmission interval: 0x10
> > > > Retransmission window: 0x02
> > > > RX packet length: 40
> > > > TX packet length: 40
> > > > Air mode: Transparent (0x03)
> > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > < ACL Data TX: Handle 34 flags 0x00 dlen 18
> > > > Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> > > > 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > > > > HCI Event: Number of Completed Packets (0x13) plen 5
> > > > Num handles: 1
> > > > Handle: 34
> > > > Count: 1
> > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > Handle: 34
> > > > Max slots: 5
> > > >
> > > > ... and SCO data are coming on SCO socket.
> > > >
> > >
> >
> > --
> > Pali Rohár
> > [email protected]
>
>
>
--
Pali Rohár
[email protected]
Hi Pali,
On Sun, May 19, 2019 at 11:23 AM Pali Rohár <[email protected]> wrote:
>
> On Sunday 19 May 2019 11:16:00 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Thu, May 16, 2019 at 9:34 PM Pali Rohár <[email protected]> wrote:
> > >
> > > Ping, can you comment anything related to hardcoded bandwidth?
> > >
> > > I would really like to take next step how to expose API for changing
> > > bandwidth as linux kernel currently does not allow to receive and
> > > transmit voice encoded by AuriStream codec.
> >
> > Didn't even know such codec existed, anyway that is not using the
> > standard AT commands so it is kind hard to figure out how to set it up
> > properly,
>
> Yes, AT+CSRSF is not standard AT command, but CSR extension. Also there
> are e.g. more headsets which support Apple extensions to AT commands...
> And Apple has public documentation for it.
>
> > to be honest, I would rather see WBS implementation finally
> > reach PA before we start digging into this.
>
> First I want to finish improving A2DP codec support in pulseaudio. Later
> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> extensible design. So the aim is that adding new codec would be very
> simple, without need to hack something related to mSBC/WBC, AuriStream
> or any other codec.
Well HSP don't have support for codec negotiation, but yes a modular
design is probably recommended.
> But for AuriStream I need to set custom SCO parameters as described
> below and currently kernel does not support it. This is why I'm asking
> how kernel can export for userspace configuration of SCO parameters...
We can always come up with socket options but we got to see the value
it would bring since AuriStream don't look that popular among
headsets, at least Ive never seem any device advertising it like
apt-X, etc.
> > > On Monday 06 May 2019 17:16:51 Pali Rohár wrote:
> > > > Ccing more people...
> > > >
> > > > do you have idea why for custom SCO HFP codec is needed to change
> > > > Transmit and Receive bandwidth in HCI Setup Synchronous Connection
> > > > packet?
> > > >
> > > > And how to expose API for userspace applications so they can change
> > > > hardcoded kernel bandwidth? Why is there value 8000?
> > > >
> > > > Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
> > > > socket for AuriStream codec in HFP profile.
> > > >
> > > > On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> > > > > Hello,
> > > > >
> > > > > I found out that more bluetooth headsets supports AuriStream codec in
> > > > > bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> > > > > ADPCM variant with better quality as default CVSD codec.
> > > > >
> > > > > Headset announce their support by sending command AT+CSRSF, in sixth
> > > > > number with first or second bit set (counted from zero). E.g.:
> > > > >
> > > > > AT+CSRSF=0,0,0,0,0,7
> > > > >
> > > > > Codec is then selected by host with sending:
> > > > >
> > > > > +CSRFN: (6,4)
> > > > > OK
> > > > >
> > > > > And answer from headset is acknowledged by another:
> > > > >
> > > > > OK
> > > > >
> > > > >
> > > > > Problem is that on Linux after issuing these AT commands I cannot longer
> > > > > connect to SCO socket. connect() fails with Protocol Error.
> > > > >
> > > > > And in btmon is following error:
> > > > >
> > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > > >
> > > > >
> > > > > In some CSR SKD is example how to activate it and there is code which
> > > > > seems to sets following HCI connection parameters:
> > > > >
> > > > > syncPktTypes = 0x003F
> > > > > bandwidth = 4000
> > > > > max_latency = 16
> > > > > voice_settings = 0x63
> > > > > retx_effort = 2
> > > > >
> > > > > I figured out that voice_settings can be configured via setsockopt()
> > > > > SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> > > > > accept only two whitelisted values: 0x0003 and 0x0060.
> > > > >
> > > > > So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
> > > > >
> > > > > In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> > > > > to Transparent, but I still got same "Invalid LMP Parameters" error.
> > > > >
> > > > > I tried to remove that whilelist from BT_VOICE option via patch below:
> > > > >
> > > > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > > > index 9a580999ca57..06db91de4f23 100644
> > > > > --- a/net/bluetooth/sco.c
> > > > > +++ b/net/bluetooth/sco.c
> > > > > @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> > > > > else
> > > > > type = SCO_LINK;
> > > > >
> > > > > - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> > > > > + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> > > > > (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> > > > > err = -EOPNOTSUPP;
> > > > > goto done;
> > > > > @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> > > > > break;
> > > > > }
> > > > >
> > > > > - /* Explicitly check for these values */
> > > > > - if (voice.setting != BT_VOICE_TRANSPARENT &&
> > > > > - voice.setting != BT_VOICE_CVSD_16BIT) {
> > > > > - err = -EINVAL;
> > > > > - break;
> > > > > - }
> > > > > -
> > > > > sco_pi(sk)->setting = voice.setting;
> > > > > break;
> > > > >
> > > > >
> > > > > Btmon now really showed Settings as 0x63, but still did not worked.
> > > > > Again exactly same HCI error.
> > > > >
> > > > > Next I tried hacking linux kernel to customize packet type and max
> > > > > latency. But even I changed these values I still got that HCI error.
> > > > >
> > > > > After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> > > > > above connection parameters), connect() syscall for that SCO socket
> > > > > succeeded and I started getting voice microphone data on that socket.
> > > > >
> > > > > And it worked also with voice settings 0x0003 with active in-kernel
> > > > > whitelist.
> > > > >
> > > > > Patch which is needed is following: Change bandwidth to 4000:
> > > > >
> > > > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > > > > index bd4978ce8c45..2dd4d0412971 100644
> > > > > --- a/net/bluetooth/hci_conn.c
> > > > > +++ b/net/bluetooth/hci_conn.c
> > > > > @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
> > > > >
> > > > > cp.handle = cpu_to_le16(handle);
> > > > >
> > > > > - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> > > > > - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> > > > > + cp.tx_bandwidth = cpu_to_le32(4000);
> > > > > + cp.rx_bandwidth = cpu_to_le32(4000);
> > > > > cp.voice_setting = cpu_to_le16(conn->setting);
> > > > >
> > > > > switch (conn->setting & SCO_AIRMODE_MASK) {
> > > > >
> > > > > I have really no idea what it does with headset. But without this patch
> > > > > I'm not able to switch HSP codec from CVSD to AuriStream.
> > > > >
> > > > > Is somebody able to explain how above change can allow opening SCO
> > > > > socket?
> > > > >
> > > > > Because without it I'm not able to activate AuriStream codec, could you
> > > > > consider allowing userspace (via some setsockoptň to change bandwidth?
> > > > > Because now it is hardcoded in kernel source code.
> > > > >
> > > > > For more details here is btmon output with default bandwidth which is
> > > > > failing:
> > > > >
> > > > > $ sudo ./monitor/btmon
> > > > > Bluetooth monitor ver 5.50
> > > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > > = Note: Bluetooth subsystem version 2.22
> > > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > > Handle: 34
> > > > > Transmit bandwidth: 8000
> > > > > Receive bandwidth: 8000
> > > > > Max latency: 13
> > > > > Setting: 0x0003
> > > > > Input Coding: Linear
> > > > > Input Data Format: 1's complement
> > > > > Input Sample Size: 8-bit
> > > > > # of bits padding at MSB: 0
> > > > > Air Coding Format: Transparent Data
> > > > > Retransmission effort: Optimize for link quality (0x02)
> > > > > Packet type: 0x0380
> > > > > 3-EV3 may not be used
> > > > > 2-EV5 may not be used
> > > > > 3-EV5 may not be used
> > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > > Status: Success (0x00)
> > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > Handle: 34
> > > > > Max slots: 1
> > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > > > Handle: 34
> > > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > > Link type: eSCO (0x02)
> > > > > Transmission interval: 0x00
> > > > > Retransmission window: 0x00
> > > > > RX packet length: 0
> > > > > TX packet length: 0
> > > > > Air mode: u-law log (0x00)
> > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > Handle: 34
> > > > > Max slots: 5
> > > > >
> > > > > And here is btmon output with above kernel patch which changes bandwidth to 4000:
> > > > >
> > > > > $ sudo ./monitor/btmon
> > > > > Bluetooth monitor ver 5.50
> > > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > > = Note: Bluetooth subsystem version 2.22
> > > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > > Handle: 34
> > > > > Transmit bandwidth: 4000
> > > > > Receive bandwidth: 4000
> > > > > Max latency: 13
> > > > > Setting: 0x0003
> > > > > Input Coding: Linear
> > > > > Input Data Format: 1's complement
> > > > > Input Sample Size: 8-bit
> > > > > # of bits padding at MSB: 0
> > > > > Air Coding Format: Transparent Data
> > > > > Retransmission effort: Optimize for link quality (0x02)
> > > > > Packet type: 0x0380
> > > > > 3-EV3 may not be used
> > > > > 2-EV5 may not be used
> > > > > 3-EV5 may not be used
> > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > > Status: Success (0x00)
> > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > Handle: 34
> > > > > Max slots: 1
> > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > Status: Success (0x00)
> > > > > Handle: 38
> > > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > > Link type: eSCO (0x02)
> > > > > Transmission interval: 0x10
> > > > > Retransmission window: 0x02
> > > > > RX packet length: 40
> > > > > TX packet length: 40
> > > > > Air mode: Transparent (0x03)
> > > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > > < ACL Data TX: Handle 34 flags 0x00 dlen 18
> > > > > Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> > > > > 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > > > > > HCI Event: Number of Completed Packets (0x13) plen 5
> > > > > Num handles: 1
> > > > > Handle: 34
> > > > > Count: 1
> > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > Handle: 34
> > > > > Max slots: 5
> > > > >
> > > > > ... and SCO data are coming on SCO socket.
> > > > >
> > > >
> > >
> > > --
> > > Pali Rohár
> > > [email protected]
> >
> >
> >
>
> --
> Pali Rohár
> [email protected]
--
Luiz Augusto von Dentz
On Sunday 19 May 2019 11:45:02 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Sun, May 19, 2019 at 11:23 AM Pali Rohár <[email protected]> wrote:
> >
> > On Sunday 19 May 2019 11:16:00 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Thu, May 16, 2019 at 9:34 PM Pali Rohár <[email protected]> wrote:
> > > >
> > > > Ping, can you comment anything related to hardcoded bandwidth?
> > > >
> > > > I would really like to take next step how to expose API for changing
> > > > bandwidth as linux kernel currently does not allow to receive and
> > > > transmit voice encoded by AuriStream codec.
> > >
> > > Didn't even know such codec existed, anyway that is not using the
> > > standard AT commands so it is kind hard to figure out how to set it up
> > > properly,
> >
> > Yes, AT+CSRSF is not standard AT command, but CSR extension. Also there
> > are e.g. more headsets which support Apple extensions to AT commands...
> > And Apple has public documentation for it.
> >
> > > to be honest, I would rather see WBS implementation finally
> > > reach PA before we start digging into this.
> >
> > First I want to finish improving A2DP codec support in pulseaudio. Later
> > I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> > extensible design. So the aim is that adding new codec would be very
> > simple, without need to hack something related to mSBC/WBC, AuriStream
> > or any other codec.
>
> Well HSP don't have support for codec negotiation, but yes a modular
> design is probably recommended.
Agree.
> > But for AuriStream I need to set custom SCO parameters as described
> > below and currently kernel does not support it. This is why I'm asking
> > how kernel can export for userspace configuration of SCO parameters...
>
> We can always come up with socket options but we got to see the value
> it would bring
As wrote in previous emails, CSR SDK uses following HCI settings for
AuriStream:
syncPktTypes = 0x003F
bandwidth = 4000
max_latency = 16
voice_settings = 0x63
retx_effort = 2
And based on my experiments without setting bandwidth to 4000, connect()
syscall fails.
> since AuriStream don't look that popular among
> headsets, at least Ive never seem any device advertising it like
> apt-X, etc.
I have never seen advertised AuriStream codec too. I just wanted to
figure out what that mysterious AT+CSRSF means and figure out that it is
CSR's custom HFP codec.
Anyway, seems that there are lot of headsets with AuriStream codec. Put
AT+CSRSF=0,0,0,0,0,7 to google search and would get lot of results of
people who pasted bluetooth logs.
So implementation of AuriStream can be really useful as it is already
widely used.
> > > > On Monday 06 May 2019 17:16:51 Pali Rohár wrote:
> > > > > Ccing more people...
> > > > >
> > > > > do you have idea why for custom SCO HFP codec is needed to change
> > > > > Transmit and Receive bandwidth in HCI Setup Synchronous Connection
> > > > > packet?
> > > > >
> > > > > And how to expose API for userspace applications so they can change
> > > > > hardcoded kernel bandwidth? Why is there value 8000?
> > > > >
> > > > > Without changing hardcoded value 8000 to 4000 I'm unable to open SCO
> > > > > socket for AuriStream codec in HFP profile.
> > > > >
> > > > > On Saturday 04 May 2019 19:15:50 Pali Rohár wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I found out that more bluetooth headsets supports AuriStream codec in
> > > > > > bluetooth HSP/HFP profile. It is proprietary CSR codec described as some
> > > > > > ADPCM variant with better quality as default CVSD codec.
> > > > > >
> > > > > > Headset announce their support by sending command AT+CSRSF, in sixth
> > > > > > number with first or second bit set (counted from zero). E.g.:
> > > > > >
> > > > > > AT+CSRSF=0,0,0,0,0,7
> > > > > >
> > > > > > Codec is then selected by host with sending:
> > > > > >
> > > > > > +CSRFN: (6,4)
> > > > > > OK
> > > > > >
> > > > > > And answer from headset is acknowledged by another:
> > > > > >
> > > > > > OK
> > > > > >
> > > > > >
> > > > > > Problem is that on Linux after issuing these AT commands I cannot longer
> > > > > > connect to SCO socket. connect() fails with Protocol Error.
> > > > > >
> > > > > > And in btmon is following error:
> > > > > >
> > > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > > > >
> > > > > >
> > > > > > In some CSR SKD is example how to activate it and there is code which
> > > > > > seems to sets following HCI connection parameters:
> > > > > >
> > > > > > syncPktTypes = 0x003F
> > > > > > bandwidth = 4000
> > > > > > max_latency = 16
> > > > > > voice_settings = 0x63
> > > > > > retx_effort = 2
> > > > > >
> > > > > > I figured out that voice_settings can be configured via setsockopt()
> > > > > > SOL_BLUETOOTH + BT_VOICE. But for some unknown reason linux kernel
> > > > > > accept only two whitelisted values: 0x0003 and 0x0060.
> > > > > >
> > > > > > So I tried to set 0x0003 value (BT_VOICE_TRANSPARENT).
> > > > > >
> > > > > > In btmon I saw that kernel really changed "Air Coding Format" from CVSD
> > > > > > to Transparent, but I still got same "Invalid LMP Parameters" error.
> > > > > >
> > > > > > I tried to remove that whilelist from BT_VOICE option via patch below:
> > > > > >
> > > > > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > > > > index 9a580999ca57..06db91de4f23 100644
> > > > > > --- a/net/bluetooth/sco.c
> > > > > > +++ b/net/bluetooth/sco.c
> > > > > > @@ -231,7 +231,7 @@ static int sco_connect(struct sock *sk)
> > > > > > else
> > > > > > type = SCO_LINK;
> > > > > >
> > > > > > - if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
> > > > > > + if ((sco_pi(sk)->setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP &&
> > > > > > (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
> > > > > > err = -EOPNOTSUPP;
> > > > > > goto done;
> > > > > > @@ -836,13 +836,6 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
> > > > > > break;
> > > > > > }
> > > > > >
> > > > > > - /* Explicitly check for these values */
> > > > > > - if (voice.setting != BT_VOICE_TRANSPARENT &&
> > > > > > - voice.setting != BT_VOICE_CVSD_16BIT) {
> > > > > > - err = -EINVAL;
> > > > > > - break;
> > > > > > - }
> > > > > > -
> > > > > > sco_pi(sk)->setting = voice.setting;
> > > > > > break;
> > > > > >
> > > > > >
> > > > > > Btmon now really showed Settings as 0x63, but still did not worked.
> > > > > > Again exactly same HCI error.
> > > > > >
> > > > > > Next I tried hacking linux kernel to customize packet type and max
> > > > > > latency. But even I changed these values I still got that HCI error.
> > > > > >
> > > > > > After I changed tx_bandwidth and rx_bandwidth to 4000 (as described in
> > > > > > above connection parameters), connect() syscall for that SCO socket
> > > > > > succeeded and I started getting voice microphone data on that socket.
> > > > > >
> > > > > > And it worked also with voice settings 0x0003 with active in-kernel
> > > > > > whitelist.
> > > > > >
> > > > > > Patch which is needed is following: Change bandwidth to 4000:
> > > > > >
> > > > > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > > > > > index bd4978ce8c45..2dd4d0412971 100644
> > > > > > --- a/net/bluetooth/hci_conn.c
> > > > > > +++ b/net/bluetooth/hci_conn.c
> > > > > > @@ -283,8 +283,8 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
> > > > > >
> > > > > > cp.handle = cpu_to_le16(handle);
> > > > > >
> > > > > > - cp.tx_bandwidth = cpu_to_le32(0x00001f40);
> > > > > > - cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> > > > > > + cp.tx_bandwidth = cpu_to_le32(4000);
> > > > > > + cp.rx_bandwidth = cpu_to_le32(4000);
> > > > > > cp.voice_setting = cpu_to_le16(conn->setting);
> > > > > >
> > > > > > switch (conn->setting & SCO_AIRMODE_MASK) {
> > > > > >
> > > > > > I have really no idea what it does with headset. But without this patch
> > > > > > I'm not able to switch HSP codec from CVSD to AuriStream.
> > > > > >
> > > > > > Is somebody able to explain how above change can allow opening SCO
> > > > > > socket?
> > > > > >
> > > > > > Because without it I'm not able to activate AuriStream codec, could you
> > > > > > consider allowing userspace (via some setsockoptň to change bandwidth?
> > > > > > Because now it is hardcoded in kernel source code.
> > > > > >
> > > > > > For more details here is btmon output with default bandwidth which is
> > > > > > failing:
> > > > > >
> > > > > > $ sudo ./monitor/btmon
> > > > > > Bluetooth monitor ver 5.50
> > > > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > > > = Note: Bluetooth subsystem version 2.22
> > > > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > > > Handle: 34
> > > > > > Transmit bandwidth: 8000
> > > > > > Receive bandwidth: 8000
> > > > > > Max latency: 13
> > > > > > Setting: 0x0003
> > > > > > Input Coding: Linear
> > > > > > Input Data Format: 1's complement
> > > > > > Input Sample Size: 8-bit
> > > > > > # of bits padding at MSB: 0
> > > > > > Air Coding Format: Transparent Data
> > > > > > Retransmission effort: Optimize for link quality (0x02)
> > > > > > Packet type: 0x0380
> > > > > > 3-EV3 may not be used
> > > > > > 2-EV5 may not be used
> > > > > > 3-EV5 may not be used
> > > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > > > Status: Success (0x00)
> > > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > > Handle: 34
> > > > > > Max slots: 1
> > > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > > Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
> > > > > > Handle: 34
> > > > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > > > Link type: eSCO (0x02)
> > > > > > Transmission interval: 0x00
> > > > > > Retransmission window: 0x00
> > > > > > RX packet length: 0
> > > > > > TX packet length: 0
> > > > > > Air mode: u-law log (0x00)
> > > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > > Handle: 34
> > > > > > Max slots: 5
> > > > > >
> > > > > > And here is btmon output with above kernel patch which changes bandwidth to 4000:
> > > > > >
> > > > > > $ sudo ./monitor/btmon
> > > > > > Bluetooth monitor ver 5.50
> > > > > > = Note: Linux version 4.9.0-9-amd64 (x86_64)
> > > > > > = Note: Bluetooth subsystem version 2.22
> > > > > > = New Index: XX:XX:XX:XX:XX:XX (Primary,USB,hci0)
> > > > > > = Open Index: XX:XX:XX:XX:XX:XX
> > > > > > = Index Info: XX:XX:XX:XX:XX:XX (Intel Corp.)
> > > > > > @ MGMT Open: bluetoothd (privileged) version 1.14
> > > > > > @ MGMT Open: btmon (privileged) version 1.14
> > > > > > < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> > > > > > Handle: 34
> > > > > > Transmit bandwidth: 4000
> > > > > > Receive bandwidth: 4000
> > > > > > Max latency: 13
> > > > > > Setting: 0x0003
> > > > > > Input Coding: Linear
> > > > > > Input Data Format: 1's complement
> > > > > > Input Sample Size: 8-bit
> > > > > > # of bits padding at MSB: 0
> > > > > > Air Coding Format: Transparent Data
> > > > > > Retransmission effort: Optimize for link quality (0x02)
> > > > > > Packet type: 0x0380
> > > > > > 3-EV3 may not be used
> > > > > > 2-EV5 may not be used
> > > > > > 3-EV5 may not be used
> > > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > > Setup Synchronous Connection (0x01|0x0028) ncmd 1
> > > > > > Status: Success (0x00)
> > > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > > Handle: 34
> > > > > > Max slots: 1
> > > > > > > HCI Event: Synchronous Connect Complete (0x2c) plen 17
> > > > > > Status: Success (0x00)
> > > > > > Handle: 38
> > > > > > Address: XX:XX:XX:XX:XX:XX (Creative Technology, Ltd.)
> > > > > > Link type: eSCO (0x02)
> > > > > > Transmission interval: 0x10
> > > > > > Retransmission window: 0x02
> > > > > > RX packet length: 40
> > > > > > TX packet length: 40
> > > > > > Air mode: Transparent (0x03)
> > > > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > > > < ACL Data TX: Handle 34 flags 0x00 dlen 18
> > > > > > Channel: 105 len 14 [PSM 0 mode 0] {chan 0}
> > > > > > 61 ef 15 0d 0a 2b 56 47 4d 3d 34 0d 0a d4 a....+VGM=4...
> > > > > > > HCI Event: Number of Completed Packets (0x13) plen 5
> > > > > > Num handles: 1
> > > > > > Handle: 34
> > > > > > Count: 1
> > > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > > > SCO Data RX: Handle 38 flags 0x00 dlen 24
> > > > > > < SCO Data TX: Handle 38 flags 0x00 dlen 48
> > > > > > > HCI Event: Max Slots Change (0x1b) plen 3
> > > > > > Handle: 34
> > > > > > Max slots: 5
> > > > > >
> > > > > > ... and SCO data are coming on SCO socket.
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Pali Rohár
> > > > [email protected]
> > >
> > >
> > >
> >
> > --
> > Pali Rohár
> > [email protected]
--
Pali Rohár
[email protected]
Hi!
> > > to be honest, I would rather see WBS implementation finally
> > > reach PA before we start digging into this.
> >
> > First I want to finish improving A2DP codec support in pulseaudio. Later
> > I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> > extensible design. So the aim is that adding new codec would be very
> > simple, without need to hack something related to mSBC/WBC, AuriStream
> > or any other codec.
>
> Well HSP don't have support for codec negotiation, but yes a modular
> design is probably recommended.
>
> > But for AuriStream I need to set custom SCO parameters as described
> > below and currently kernel does not support it. This is why I'm asking
> > how kernel can export for userspace configuration of SCO parameters...
>
> We can always come up with socket options but we got to see the value
> it would bring since AuriStream don't look that popular among
> headsets, at least Ive never seem any device advertising it like
> apt-X, etc.
Pali clearly has such device and he is willing to work on it. Surely
that means it is popular enough to be supported...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sunday 19 May 2019 23:21:58 Pavel Machek wrote:
> Hi!
>
> > > > to be honest, I would rather see WBS implementation finally
> > > > reach PA before we start digging into this.
> > >
> > > First I want to finish improving A2DP codec support in pulseaudio. Later
> > > I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> > > extensible design. So the aim is that adding new codec would be very
> > > simple, without need to hack something related to mSBC/WBC, AuriStream
> > > or any other codec.
> >
> > Well HSP don't have support for codec negotiation, but yes a modular
> > design is probably recommended.
> >
> > > But for AuriStream I need to set custom SCO parameters as described
> > > below and currently kernel does not support it. This is why I'm asking
> > > how kernel can export for userspace configuration of SCO parameters...
> >
> > We can always come up with socket options but we got to see the value
> > it would bring since AuriStream don't look that popular among
> > headsets, at least Ive never seem any device advertising it like
> > apt-X, etc.
>
> Pali clearly has such device and he is willing to work on it. Surely
> that means it is popular enough to be supported...?
Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
not only I have such device...
So I would really would like to see that kernel finally stops blocking
usage of this AuriStream codec.
--
Pali Rohár
[email protected]
Hi Pali,
On Fri, Jun 7, 2019 at 4:02 PM Pali Rohár <[email protected]> wrote:
>
> On Sunday 19 May 2019 23:21:58 Pavel Machek wrote:
> > Hi!
> >
> > > > > to be honest, I would rather see WBS implementation finally
> > > > > reach PA before we start digging into this.
> > > >
> > > > First I want to finish improving A2DP codec support in pulseaudio. Later
> > > > I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> > > > extensible design. So the aim is that adding new codec would be very
> > > > simple, without need to hack something related to mSBC/WBC, AuriStream
> > > > or any other codec.
> > >
> > > Well HSP don't have support for codec negotiation, but yes a modular
> > > design is probably recommended.
> > >
> > > > But for AuriStream I need to set custom SCO parameters as described
> > > > below and currently kernel does not support it. This is why I'm asking
> > > > how kernel can export for userspace configuration of SCO parameters...
> > >
> > > We can always come up with socket options but we got to see the value
> > > it would bring since AuriStream don't look that popular among
> > > headsets, at least Ive never seem any device advertising it like
> > > apt-X, etc.
> >
> > Pali clearly has such device and he is willing to work on it. Surely
> > that means it is popular enough to be supported...?
>
> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> not only I have such device...
>
> So I would really would like to see that kernel finally stops blocking
> usage of this AuriStream codec.
Well I guess it is up to you to make the changes then.
--
Luiz Augusto von Dentz
Hi Pali,
>>>>> to be honest, I would rather see WBS implementation finally
>>>>> reach PA before we start digging into this.
>>>>
>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>> extensible design. So the aim is that adding new codec would be very
>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>> or any other codec.
>>>
>>> Well HSP don't have support for codec negotiation, but yes a modular
>>> design is probably recommended.
>>>
>>>> But for AuriStream I need to set custom SCO parameters as described
>>>> below and currently kernel does not support it. This is why I'm asking
>>>> how kernel can export for userspace configuration of SCO parameters...
>>>
>>> We can always come up with socket options but we got to see the value
>>> it would bring since AuriStream don't look that popular among
>>> headsets, at least Ive never seem any device advertising it like
>>> apt-X, etc.
>>
>> Pali clearly has such device and he is willing to work on it. Surely
>> that means it is popular enough to be supported...?
>
> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> not only I have such device...
>
> So I would really would like to see that kernel finally stops blocking
> usage of this AuriStream codec.
we need to figure out on how we do the kernel API to allow you this specific setting. We have kept is really simple since there was only CVSD and mSBC as of now. I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
Regards
Marcel
On Saturday 06 July 2019 15:45:03 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>> to be honest, I would rather see WBS implementation finally
> >>>>> reach PA before we start digging into this.
> >>>>
> >>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>> extensible design. So the aim is that adding new codec would be very
> >>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>> or any other codec.
> >>>
> >>> Well HSP don't have support for codec negotiation, but yes a modular
> >>> design is probably recommended.
> >>>
> >>>> But for AuriStream I need to set custom SCO parameters as described
> >>>> below and currently kernel does not support it. This is why I'm asking
> >>>> how kernel can export for userspace configuration of SCO parameters...
> >>>
> >>> We can always come up with socket options but we got to see the value
> >>> it would bring since AuriStream don't look that popular among
> >>> headsets, at least Ive never seem any device advertising it like
> >>> apt-X, etc.
> >>
> >> Pali clearly has such device and he is willing to work on it. Surely
> >> that means it is popular enough to be supported...?
> >
> > Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> > not only I have such device...
> >
> > So I would really would like to see that kernel finally stops blocking
> > usage of this AuriStream codec.
>
> we need to figure out on how we do the kernel API to allow you this specific setting.
Hi Marcel! Kernel API for userspace should be simple. Just add two
ioctls for retrieving and setting structure with custom parameters:
syncPktTypes = 0x003F
bandwidth = 4000
max_latency = 16
voice_settings = 0x63
retx_effort = 2
Or add more ioctls, one ioctl per parameter. There is already only ioctl
for voice settings and moreover it is whitelisted only for two values.
> We have kept is really simple since there was only CVSD and mSBC as of now.
Seems that custom codecs are already widely used, so it would be great
it Linux kernel allows to use also other codecs in future without need
to explicitly whitelist them.
> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
I did all above tests and kernel changes with USB bluetooth chip which
is integrated in notebook's combo bt+wifi intel minipci-e card.
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>> reach PA before we start digging into this.
>>>>>>
>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>> or any other codec.
>>>>>
>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>> design is probably recommended.
>>>>>
>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>
>>>>> We can always come up with socket options but we got to see the value
>>>>> it would bring since AuriStream don't look that popular among
>>>>> headsets, at least Ive never seem any device advertising it like
>>>>> apt-X, etc.
>>>>
>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>> that means it is popular enough to be supported...?
>>>
>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>> not only I have such device...
>>>
>>> So I would really would like to see that kernel finally stops blocking
>>> usage of this AuriStream codec.
>>
>> we need to figure out on how we do the kernel API to allow you this specific setting.
>
> Hi Marcel! Kernel API for userspace should be simple. Just add two
> ioctls for retrieving and setting structure with custom parameters:
>
> syncPktTypes = 0x003F
> bandwidth = 4000
> max_latency = 16
> voice_settings = 0x63
> retx_effort = 2
>
> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> for voice settings and moreover it is whitelisted only for two values.
it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>> We have kept is really simple since there was only CVSD and mSBC as of now.
>
> Seems that custom codecs are already widely used, so it would be great
> it Linux kernel allows to use also other codecs in future without need
> to explicitly whitelist them.
This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
>> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
>
> I did all above tests and kernel changes with USB bluetooth chip which
> is integrated in notebook's combo bt+wifi intel minipci-e card.
Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.
Regards
Marcel
On Monday 08 July 2019 15:23:06 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>> reach PA before we start digging into this.
> >>>>>>
> >>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>> or any other codec.
> >>>>>
> >>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>> design is probably recommended.
> >>>>>
> >>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>>
> >>>>> We can always come up with socket options but we got to see the value
> >>>>> it would bring since AuriStream don't look that popular among
> >>>>> headsets, at least Ive never seem any device advertising it like
> >>>>> apt-X, etc.
> >>>>
> >>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>> that means it is popular enough to be supported...?
> >>>
> >>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>> not only I have such device...
> >>>
> >>> So I would really would like to see that kernel finally stops blocking
> >>> usage of this AuriStream codec.
> >>
> >> we need to figure out on how we do the kernel API to allow you this specific setting.
> >
> > Hi Marcel! Kernel API for userspace should be simple. Just add two
> > ioctls for retrieving and setting structure with custom parameters:
> >
> > syncPktTypes = 0x003F
> > bandwidth = 4000
> > max_latency = 16
> > voice_settings = 0x63
> > retx_effort = 2
> >
> > Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > for voice settings and moreover it is whitelisted only for two values.
>
> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
Ok. I see that there is another "example" configuration for AuriStream
with just different syncPktTypes = 0x02BF and bandwidth = 3850.
So it really is not simple as it can be seen.
> >> We have kept is really simple since there was only CVSD and mSBC as of now.
> >
> > Seems that custom codecs are already widely used, so it would be great
> > it Linux kernel allows to use also other codecs in future without need
> > to explicitly whitelist them.
>
> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
codecs but I have not seen it used. Has somebody tried to implement it?
I think just replacing voice_settings should be enough as encoding /
decoding should be done in bluetooth firmware / hardware.
And then there is AuriStream which based on google results it supported
by lot of headsets.
So at least 3 different codecs are widely supported by headset.
> >> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
> >
> > I did all above tests and kernel changes with USB bluetooth chip which
> > is integrated in notebook's combo bt+wifi intel minipci-e card.
>
> Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.
I understood that both mSBC and AuriStream uses "transparent" mode of
transport and bluetooth chip itself does not know if it transmit mSBC or
AuriStream as it does not do any encoding...
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>>>> reach PA before we start digging into this.
>>>>>>>>
>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>>>> or any other codec.
>>>>>>>
>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>>>> design is probably recommended.
>>>>>>>
>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>>>
>>>>>>> We can always come up with socket options but we got to see the value
>>>>>>> it would bring since AuriStream don't look that popular among
>>>>>>> headsets, at least Ive never seem any device advertising it like
>>>>>>> apt-X, etc.
>>>>>>
>>>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>>>> that means it is popular enough to be supported...?
>>>>>
>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>>>> not only I have such device...
>>>>>
>>>>> So I would really would like to see that kernel finally stops blocking
>>>>> usage of this AuriStream codec.
>>>>
>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
>>>
>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
>>> ioctls for retrieving and setting structure with custom parameters:
>>>
>>> syncPktTypes = 0x003F
>>> bandwidth = 4000
>>> max_latency = 16
>>> voice_settings = 0x63
>>> retx_effort = 2
>>>
>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
>>> for voice settings and moreover it is whitelisted only for two values.
>>
>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>
> Ok. I see that there is another "example" configuration for AuriStream
> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
>
> So it really is not simple as it can be seen.
currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>>>> We have kept is really simple since there was only CVSD and mSBC as of now.
>>>
>>> Seems that custom codecs are already widely used, so it would be great
>>> it Linux kernel allows to use also other codecs in future without need
>>> to explicitly whitelist them.
>>
>> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
>
> CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
> codecs but I have not seen it used. Has somebody tried to implement it?
> I think just replacing voice_settings should be enough as encoding /
> decoding should be done in bluetooth firmware / hardware.
>
> And then there is AuriStream which based on google results it supported
> by lot of headsets.
>
> So at least 3 different codecs are widely supported by headset.
The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream.
>>>> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
>>>
>>> I did all above tests and kernel changes with USB bluetooth chip which
>>> is integrated in notebook's combo bt+wifi intel minipci-e card.
>>
>> Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.
>
> I understood that both mSBC and AuriStream uses "transparent" mode of
> transport and bluetooth chip itself does not know if it transmit mSBC or
> AuriStream as it does not do any encoding…
That is true, but still for transparent codec they defined a new alternate setting for USB.
Regards
Marcel
On Friday 12 July 2019 20:59:22 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>>>> reach PA before we start digging into this.
> >>>>>>>>
> >>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>>>> or any other codec.
> >>>>>>>
> >>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>>>> design is probably recommended.
> >>>>>>>
> >>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>>>>
> >>>>>>> We can always come up with socket options but we got to see the value
> >>>>>>> it would bring since AuriStream don't look that popular among
> >>>>>>> headsets, at least Ive never seem any device advertising it like
> >>>>>>> apt-X, etc.
> >>>>>>
> >>>>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>>>> that means it is popular enough to be supported...?
> >>>>>
> >>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>>>> not only I have such device...
> >>>>>
> >>>>> So I would really would like to see that kernel finally stops blocking
> >>>>> usage of this AuriStream codec.
> >>>>
> >>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> >>>
> >>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> >>> ioctls for retrieving and setting structure with custom parameters:
> >>>
> >>> syncPktTypes = 0x003F
> >>> bandwidth = 4000
> >>> max_latency = 16
> >>> voice_settings = 0x63
> >>> retx_effort = 2
> >>>
> >>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> >>> for voice settings and moreover it is whitelisted only for two values.
> >>
> >> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> >
> > Ok. I see that there is another "example" configuration for AuriStream
> > with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> >
> > So it really is not simple as it can be seen.
>
> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
>
> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
>
> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
Ok. I will look at it and I will try to propose how to extend current
BT_VOICE ioctl API for supporting all those new parameters.
> >>>> We have kept is really simple since there was only CVSD and mSBC as of now.
> >>>
> >>> Seems that custom codecs are already widely used, so it would be great
> >>> it Linux kernel allows to use also other codecs in future without need
> >>> to explicitly whitelist them.
> >>
> >> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
> >
> > CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
> > codecs but I have not seen it used. Has somebody tried to implement it?
> > I think just replacing voice_settings should be enough as encoding /
> > decoding should be done in bluetooth firmware / hardware.
> >
> > And then there is AuriStream which based on google results it supported
> > by lot of headsets.
> >
> > So at least 3 different codecs are widely supported by headset.
>
> The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream.
More interesting question would be if alaw codec can be used in
transparent mode by transmitter and in "normal alaw" mode by receiver.
So it is possible to "tell" bluetooth chip "hey, I have already prepared
alaw or CVSD packets for you"?
In Europe all landline phones (and also their SIP non-compressed
equivalents) use alaw codec. So ability to pass SIP alaw samples
directly to headset could increase quality of SIP calls. As currently
received alaw samples are converted to linear PCM, then send to
bluetooth chip which converts it into CVSD codec and finally bluetooth
headset converts CVSD to analog.
> >>>> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
> >>>
> >>> I did all above tests and kernel changes with USB bluetooth chip which
> >>> is integrated in notebook's combo bt+wifi intel minipci-e card.
> >>
> >> Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.
> >
> > I understood that both mSBC and AuriStream uses "transparent" mode of
> > transport and bluetooth chip itself does not know if it transmit mSBC or
> > AuriStream as it does not do any encoding…
>
> That is true, but still for transparent codec they defined a new alternate setting for USB.
So is btintel/btusb already handles it? Or btusb needs to be patches for
"proper" support?
> Regards
>
> Marcel
>
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>>>>>> reach PA before we start digging into this.
>>>>>>>>>>
>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>>>>>> or any other codec.
>>>>>>>>>
>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>>>>>> design is probably recommended.
>>>>>>>>>
>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>>>>>
>>>>>>>>> We can always come up with socket options but we got to see the value
>>>>>>>>> it would bring since AuriStream don't look that popular among
>>>>>>>>> headsets, at least Ive never seem any device advertising it like
>>>>>>>>> apt-X, etc.
>>>>>>>>
>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>>>>>> that means it is popular enough to be supported...?
>>>>>>>
>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>>>>>> not only I have such device...
>>>>>>>
>>>>>>> So I would really would like to see that kernel finally stops blocking
>>>>>>> usage of this AuriStream codec.
>>>>>>
>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
>>>>>
>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
>>>>> ioctls for retrieving and setting structure with custom parameters:
>>>>>
>>>>> syncPktTypes = 0x003F
>>>>> bandwidth = 4000
>>>>> max_latency = 16
>>>>> voice_settings = 0x63
>>>>> retx_effort = 2
>>>>>
>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
>>>>> for voice settings and moreover it is whitelisted only for two values.
>>>>
>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>>>
>>> Ok. I see that there is another "example" configuration for AuriStream
>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
>>>
>>> So it really is not simple as it can be seen.
>>
>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
>>
>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
>>
>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>
> Ok. I will look at it and I will try to propose how to extend current
> BT_VOICE ioctl API for supporting all those new parameters.
>
>>>>>> We have kept is really simple since there was only CVSD and mSBC as of now.
>>>>>
>>>>> Seems that custom codecs are already widely used, so it would be great
>>>>> it Linux kernel allows to use also other codecs in future without need
>>>>> to explicitly whitelist them.
>>>>
>>>> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
>>>
>>> CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
>>> codecs but I have not seen it used. Has somebody tried to implement it?
>>> I think just replacing voice_settings should be enough as encoding /
>>> decoding should be done in bluetooth firmware / hardware.
>>>
>>> And then there is AuriStream which based on google results it supported
>>> by lot of headsets.
>>>
>>> So at least 3 different codecs are widely supported by headset.
>>
>> The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream.
>
> More interesting question would be if alaw codec can be used in
> transparent mode by transmitter and in "normal alaw" mode by receiver.
> So it is possible to "tell" bluetooth chip "hey, I have already prepared
> alaw or CVSD packets for you”?
actually alaw is an over the air codec. Using it in transparent mode has no profile support. So while possible, it is not interoperable.
> In Europe all landline phones (and also their SIP non-compressed
> equivalents) use alaw codec. So ability to pass SIP alaw samples
> directly to headset could increase quality of SIP calls. As currently
> received alaw samples are converted to linear PCM, then send to
> bluetooth chip which converts it into CVSD codec and finally bluetooth
> headset converts CVSD to analog.
Nice idea, but not worth the effort.
>>>>>> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
>>>>>
>>>>> I did all above tests and kernel changes with USB bluetooth chip which
>>>>> is integrated in notebook's combo bt+wifi intel minipci-e card.
>>>>
>>>> Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.
>>>
>>> I understood that both mSBC and AuriStream uses "transparent" mode of
>>> transport and bluetooth chip itself does not know if it transmit mSBC or
>>> AuriStream as it does not do any encoding…
>>
>> That is true, but still for transparent codec they defined a new alternate setting for USB.
>
> So is btintel/btusb already handles it? Or btusb needs to be patches for
> "proper" support?
It should handle it, but we only know when this is fully tested.
Regards
Marcel
On Thursday 18 July 2019 12:09:39 Pali Rohár wrote:
> On Friday 12 July 2019 20:59:22 Marcel Holtmann wrote:
> > Hi Pali,
> >
> > >>>>>>>>> to be honest, I would rather see WBS implementation finally
> > >>>>>>>>> reach PA before we start digging into this.
> > >>>>>>>>
> > >>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> > >>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> > >>>>>>>> extensible design. So the aim is that adding new codec would be very
> > >>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> > >>>>>>>> or any other codec.
> > >>>>>>>
> > >>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
> > >>>>>>> design is probably recommended.
> > >>>>>>>
> > >>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> > >>>>>>>> below and currently kernel does not support it. This is why I'm asking
> > >>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> > >>>>>>>
> > >>>>>>> We can always come up with socket options but we got to see the value
> > >>>>>>> it would bring since AuriStream don't look that popular among
> > >>>>>>> headsets, at least Ive never seem any device advertising it like
> > >>>>>>> apt-X, etc.
> > >>>>>>
> > >>>>>> Pali clearly has such device and he is willing to work on it. Surely
> > >>>>>> that means it is popular enough to be supported...?
> > >>>>>
> > >>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> > >>>>> not only I have such device...
> > >>>>>
> > >>>>> So I would really would like to see that kernel finally stops blocking
> > >>>>> usage of this AuriStream codec.
> > >>>>
> > >>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> > >>>
> > >>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> > >>> ioctls for retrieving and setting structure with custom parameters:
> > >>>
> > >>> syncPktTypes = 0x003F
> > >>> bandwidth = 4000
> > >>> max_latency = 16
> > >>> voice_settings = 0x63
> > >>> retx_effort = 2
> > >>>
> > >>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > >>> for voice settings and moreover it is whitelisted only for two values.
> > >>
> > >> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> > >
> > > Ok. I see that there is another "example" configuration for AuriStream
> > > with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> > >
> > > So it really is not simple as it can be seen.
> >
> > currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> >
> > So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> >
> > My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>
> Ok. I will look at it and I will try to propose how to extend current
> BT_VOICE ioctl API for supporting all those new parameters.
Below is inline MIME part with POC patch which try to implement a new
IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
settings.
It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
voice_setting, pkt_type, max_latency, retrans_effort>, but with
maximally 10 array members (due to usage of static array storage). cvsd
codec uses 7 different fallback settings (see voice_setup_cvsd), so for
POC 10 should be enough.
Because a new IOCL has different members then old BT_VOICE I rather
decided to introduce a new IOCTL and not hacking old IOCTL to accept two
different structures.
Please let me know what do you think about this API, if this is a way
how to continue or if something different is needed.
--
Pali Rohár
[email protected]
Hi!
> > > >>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> > > >>>>>>>> below and currently kernel does not support it. This is why I'm asking
> > > >>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> > > >>>>>>>
> > > >>>>>>> We can always come up with socket options but we got to see the value
> > > >>>>>>> it would bring since AuriStream don't look that popular among
> > > >>>>>>> headsets, at least Ive never seem any device advertising it like
> > > >>>>>>> apt-X, etc.
> > > >>>>>>
> > > >>>>>> Pali clearly has such device and he is willing to work on it. Surely
> > > >>>>>> that means it is popular enough to be supported...?
> > > >>>>>
> > > >>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> > > >>>>> not only I have such device...
> > > >>>>>
> > > >>>>> So I would really would like to see that kernel finally stops blocking
> > > >>>>> usage of this AuriStream codec.
> > > >>>>
> > > >>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> > > >>>
> > > >>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> > > >>> ioctls for retrieving and setting structure with custom parameters:
> > > >>>
> > > >>> syncPktTypes = 0x003F
> > > >>> bandwidth = 4000
> > > >>> max_latency = 16
> > > >>> voice_settings = 0x63
> > > >>> retx_effort = 2
> > > >>>
> > > >>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > > >>> for voice settings and moreover it is whitelisted only for two values.
> > > >>
> > > >> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> > > >
> > > > Ok. I see that there is another "example" configuration for AuriStream
> > > > with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> > > >
> > > > So it really is not simple as it can be seen.
> > >
> > > currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> > >
> > > So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> > >
> > > My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> >
> > Ok. I will look at it and I will try to propose how to extend current
> > BT_VOICE ioctl API for supporting all those new parameters.
>
> Below is inline MIME part with POC patch which try to implement a new
> IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> settings.
>
> It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> voice_setting, pkt_type, max_latency, retrans_effort>, but with
> maximally 10 array members (due to usage of static array storage). cvsd
> codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> POC 10 should be enough.
>
> Because a new IOCL has different members then old BT_VOICE I rather
> decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> different structures.
>
> Please let me know what do you think about this API, if this is a way
> how to continue or if something different is needed.
New ioctl sounds like good idea.
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index fabee6db0abb..0e9f4ac07220 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -122,6 +122,19 @@ struct bt_voice {
> #define BT_SNDMTU 12
> #define BT_RCVMTU 13
>
> +#define BT_VOICE_SETUP 14
> +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> +struct bt_voice_setup {
> + __u8 sco_capable:1;
> + __u8 esco_capable:1;
> + __u32 tx_bandwidth;
> + __u32 rx_bandwidth;
> + __u16 voice_setting;
> + __u16 pkt_type;
> + __u16 max_latency;
> + __u8 retrans_effort;
> +};
> +
Is this the new ioctl? I'd assume it should go to include/user/..
somewhere to be exported to userspace...?
Is it good idea to use __u8 :1 in user<->kernel API?
Pavel
On Tuesday 12 November 2019 22:06:33 Pavel Machek wrote:
> Hi!
>
> > > > >>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> > > > >>>>>>>> below and currently kernel does not support it. This is why I'm asking
> > > > >>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> > > > >>>>>>>
> > > > >>>>>>> We can always come up with socket options but we got to see the value
> > > > >>>>>>> it would bring since AuriStream don't look that popular among
> > > > >>>>>>> headsets, at least Ive never seem any device advertising it like
> > > > >>>>>>> apt-X, etc.
> > > > >>>>>>
> > > > >>>>>> Pali clearly has such device and he is willing to work on it. Surely
> > > > >>>>>> that means it is popular enough to be supported...?
> > > > >>>>>
> > > > >>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> > > > >>>>> not only I have such device...
> > > > >>>>>
> > > > >>>>> So I would really would like to see that kernel finally stops blocking
> > > > >>>>> usage of this AuriStream codec.
> > > > >>>>
> > > > >>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> > > > >>>
> > > > >>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> > > > >>> ioctls for retrieving and setting structure with custom parameters:
> > > > >>>
> > > > >>> syncPktTypes = 0x003F
> > > > >>> bandwidth = 4000
> > > > >>> max_latency = 16
> > > > >>> voice_settings = 0x63
> > > > >>> retx_effort = 2
> > > > >>>
> > > > >>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > > > >>> for voice settings and moreover it is whitelisted only for two values.
> > > > >>
> > > > >> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> > > > >
> > > > > Ok. I see that there is another "example" configuration for AuriStream
> > > > > with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> > > > >
> > > > > So it really is not simple as it can be seen.
> > > >
> > > > currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> > > >
> > > > So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> > > >
> > > > My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> > >
> > > Ok. I will look at it and I will try to propose how to extend current
> > > BT_VOICE ioctl API for supporting all those new parameters.
> >
> > Below is inline MIME part with POC patch which try to implement a new
> > IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> > settings.
> >
> > It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> > voice_setting, pkt_type, max_latency, retrans_effort>, but with
> > maximally 10 array members (due to usage of static array storage). cvsd
> > codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> > POC 10 should be enough.
> >
> > Because a new IOCL has different members then old BT_VOICE I rather
> > decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> > different structures.
> >
> > Please let me know what do you think about this API, if this is a way
> > how to continue or if something different is needed.
>
>
> New ioctl sounds like good idea.
>
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index fabee6db0abb..0e9f4ac07220 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -122,6 +122,19 @@ struct bt_voice {
> > #define BT_SNDMTU 12
> > #define BT_RCVMTU 13
> >
> > +#define BT_VOICE_SETUP 14
> > +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> > +struct bt_voice_setup {
> > + __u8 sco_capable:1;
> > + __u8 esco_capable:1;
> > + __u32 tx_bandwidth;
> > + __u32 rx_bandwidth;
> > + __u16 voice_setting;
> > + __u16 pkt_type;
> > + __u16 max_latency;
> > + __u8 retrans_effort;
> > +};
> > +
>
> Is this the new ioctl? I'd assume it should go to include/user/..
> somewhere to be exported to userspace...?
I put it into same file where is structure for old ioctl BT_VOICE.
> Is it good idea to use __u8 :1 in user<->kernel API?
I do not know. Should it be rather (C99) bool? Or just one __u8?
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>>>>>>> reach PA before we start digging into this.
>>>>>>>>>>>
>>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>>>>>>> or any other codec.
>>>>>>>>>>
>>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>>>>>>> design is probably recommended.
>>>>>>>>>>
>>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>>>>>>
>>>>>>>>>> We can always come up with socket options but we got to see the value
>>>>>>>>>> it would bring since AuriStream don't look that popular among
>>>>>>>>>> headsets, at least Ive never seem any device advertising it like
>>>>>>>>>> apt-X, etc.
>>>>>>>>>
>>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>>>>>>> that means it is popular enough to be supported...?
>>>>>>>>
>>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>>>>>>> not only I have such device...
>>>>>>>>
>>>>>>>> So I would really would like to see that kernel finally stops blocking
>>>>>>>> usage of this AuriStream codec.
>>>>>>>
>>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
>>>>>>
>>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
>>>>>> ioctls for retrieving and setting structure with custom parameters:
>>>>>>
>>>>>> syncPktTypes = 0x003F
>>>>>> bandwidth = 4000
>>>>>> max_latency = 16
>>>>>> voice_settings = 0x63
>>>>>> retx_effort = 2
>>>>>>
>>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
>>>>>> for voice settings and moreover it is whitelisted only for two values.
>>>>>
>>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>>>>
>>>> Ok. I see that there is another "example" configuration for AuriStream
>>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
>>>>
>>>> So it really is not simple as it can be seen.
>>>
>>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
>>>
>>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
>>>
>>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>>
>> Ok. I will look at it and I will try to propose how to extend current
>> BT_VOICE ioctl API for supporting all those new parameters.
>
> Below is inline MIME part with POC patch which try to implement a new
> IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> settings.
>
> It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> voice_setting, pkt_type, max_latency, retrans_effort>, but with
> maximally 10 array members (due to usage of static array storage). cvsd
> codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> POC 10 should be enough.
>
> Because a new IOCL has different members then old BT_VOICE I rather
> decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> different structures.
>
> Please let me know what do you think about this API, if this is a way
> how to continue or if something different is needed.
>
> --
> Pali Rohár
> [email protected]
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index fabee6db0abb..0e9f4ac07220 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -122,6 +122,19 @@ struct bt_voice {
> #define BT_SNDMTU 12
> #define BT_RCVMTU 13
>
> +#define BT_VOICE_SETUP 14
> +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> +struct bt_voice_setup {
> + __u8 sco_capable:1;
> + __u8 esco_capable:1;
> + __u32 tx_bandwidth;
> + __u32 rx_bandwidth;
> + __u16 voice_setting;
> + __u16 pkt_type;
> + __u16 max_latency;
> + __u8 retrans_effort;
> +};
> +
> __printf(1, 2)
> void bt_info(const char *fmt, ...);
> __printf(1, 2)
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 094e61e07030..8f3c161da1c4 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -477,7 +477,7 @@ struct hci_conn {
> __u8 passkey_entered;
> __u16 disc_timeout;
> __u16 conn_timeout;
> - __u16 setting;
> + struct bt_voice_setup voice_setup[BT_VOICE_SETUP_ARRAY_SIZE];
> __u16 le_conn_min_interval;
> __u16 le_conn_max_interval;
> __u16 le_conn_interval;
> @@ -897,8 +897,8 @@ static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
> }
>
> int hci_disconnect(struct hci_conn *conn, __u8 reason);
> -bool hci_setup_sync(struct hci_conn *conn, __u16 handle);
> -void hci_sco_setup(struct hci_conn *conn, __u8 status);
> +int hci_setup_sync(struct hci_conn *conn, __u16 handle);
> +int hci_sco_setup(struct hci_conn *conn, __u8 status);
>
> struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
> u8 role);
> @@ -920,7 +920,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
> struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
> u8 sec_level, u8 auth_type);
> struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
> - __u16 setting);
> + struct bt_voice_setup *voice_setup);
> int hci_conn_check_link_mode(struct hci_conn *conn);
> int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
> int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index bd4978ce8c45..0aa2ad98eb80 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -35,30 +35,6 @@
> #include "smp.h"
> #include "a2mp.h"
>
> -struct sco_param {
> - u16 pkt_type;
> - u16 max_latency;
> - u8 retrans_effort;
> -};
> -
> -static const struct sco_param esco_param_cvsd[] = {
> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
> - { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
> -};
> -
> -static const struct sco_param sco_param_cvsd[] = {
> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
> -};
> -
> -static const struct sco_param esco_param_msbc[] = {
> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d, 0x02 }, /* T2 */
> - { EDR_ESCO_MASK | ESCO_EV3, 0x0008, 0x02 }, /* T1 */
> -};
> -
can you split this into multiple logical patches. And ensure sending it with git send-email.
Regards
Marcel
On Tuesday 19 November 2019 18:04:36 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>>>>>>> reach PA before we start digging into this.
> >>>>>>>>>>>
> >>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>>>>>>> or any other codec.
> >>>>>>>>>>
> >>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>>>>>>> design is probably recommended.
> >>>>>>>>>>
> >>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>>>>>>>
> >>>>>>>>>> We can always come up with socket options but we got to see the value
> >>>>>>>>>> it would bring since AuriStream don't look that popular among
> >>>>>>>>>> headsets, at least Ive never seem any device advertising it like
> >>>>>>>>>> apt-X, etc.
> >>>>>>>>>
> >>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>>>>>>> that means it is popular enough to be supported...?
> >>>>>>>>
> >>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>>>>>>> not only I have such device...
> >>>>>>>>
> >>>>>>>> So I would really would like to see that kernel finally stops blocking
> >>>>>>>> usage of this AuriStream codec.
> >>>>>>>
> >>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> >>>>>>
> >>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> >>>>>> ioctls for retrieving and setting structure with custom parameters:
> >>>>>>
> >>>>>> syncPktTypes = 0x003F
> >>>>>> bandwidth = 4000
> >>>>>> max_latency = 16
> >>>>>> voice_settings = 0x63
> >>>>>> retx_effort = 2
> >>>>>>
> >>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> >>>>>> for voice settings and moreover it is whitelisted only for two values.
> >>>>>
> >>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> >>>>
> >>>> Ok. I see that there is another "example" configuration for AuriStream
> >>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> >>>>
> >>>> So it really is not simple as it can be seen.
> >>>
> >>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> >>>
> >>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> >>>
> >>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> >>
> >> Ok. I will look at it and I will try to propose how to extend current
> >> BT_VOICE ioctl API for supporting all those new parameters.
> >
> > Below is inline MIME part with POC patch which try to implement a new
> > IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> > settings.
> >
> > It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> > voice_setting, pkt_type, max_latency, retrans_effort>, but with
> > maximally 10 array members (due to usage of static array storage). cvsd
> > codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> > POC 10 should be enough.
> >
> > Because a new IOCL has different members then old BT_VOICE I rather
> > decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> > different structures.
> >
> > Please let me know what do you think about this API, if this is a way
> > how to continue or if something different is needed.
> >
> > --
> > Pali Rohár
> > [email protected]
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index fabee6db0abb..0e9f4ac07220 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -122,6 +122,19 @@ struct bt_voice {
> > #define BT_SNDMTU 12
> > #define BT_RCVMTU 13
> >
> > +#define BT_VOICE_SETUP 14
> > +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> > +struct bt_voice_setup {
> > + __u8 sco_capable:1;
> > + __u8 esco_capable:1;
> > + __u32 tx_bandwidth;
> > + __u32 rx_bandwidth;
> > + __u16 voice_setting;
> > + __u16 pkt_type;
> > + __u16 max_latency;
> > + __u8 retrans_effort;
> > +};
> > +
> > __printf(1, 2)
> > void bt_info(const char *fmt, ...);
> > __printf(1, 2)
> > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > index 094e61e07030..8f3c161da1c4 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -477,7 +477,7 @@ struct hci_conn {
> > __u8 passkey_entered;
> > __u16 disc_timeout;
> > __u16 conn_timeout;
> > - __u16 setting;
> > + struct bt_voice_setup voice_setup[BT_VOICE_SETUP_ARRAY_SIZE];
> > __u16 le_conn_min_interval;
> > __u16 le_conn_max_interval;
> > __u16 le_conn_interval;
> > @@ -897,8 +897,8 @@ static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
> > }
> >
> > int hci_disconnect(struct hci_conn *conn, __u8 reason);
> > -bool hci_setup_sync(struct hci_conn *conn, __u16 handle);
> > -void hci_sco_setup(struct hci_conn *conn, __u8 status);
> > +int hci_setup_sync(struct hci_conn *conn, __u16 handle);
> > +int hci_sco_setup(struct hci_conn *conn, __u8 status);
> >
> > struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
> > u8 role);
> > @@ -920,7 +920,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
> > struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
> > u8 sec_level, u8 auth_type);
> > struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
> > - __u16 setting);
> > + struct bt_voice_setup *voice_setup);
> > int hci_conn_check_link_mode(struct hci_conn *conn);
> > int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
> > int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index bd4978ce8c45..0aa2ad98eb80 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -35,30 +35,6 @@
> > #include "smp.h"
> > #include "a2mp.h"
> >
> > -struct sco_param {
> > - u16 pkt_type;
> > - u16 max_latency;
> > - u8 retrans_effort;
> > -};
> > -
> > -static const struct sco_param esco_param_cvsd[] = {
> > - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
> > - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
> > - { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
> > - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
> > - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
> > -};
> > -
> > -static const struct sco_param sco_param_cvsd[] = {
> > - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
> > - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
> > -};
> > -
> > -static const struct sco_param esco_param_msbc[] = {
> > - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d, 0x02 }, /* T2 */
> > - { EDR_ESCO_MASK | ESCO_EV3, 0x0008, 0x02 }, /* T1 */
> > -};
> > -
>
> can you split this into multiple logical patches. And ensure sending it with git send-email.
I just send it as is to know if such API make sense and should I
continue or not. Preparing patches for git send-email takes a lot of
time and I wanted to know if such API is OK or should be fully
rewritten. So I do not spend on something which does not make sense.
Above patch is not mean to be complete not ready for merge.
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>>>>>>>>> reach PA before we start digging into this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>>>>>>>>> or any other codec.
>>>>>>>>>>>>
>>>>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>>>>>>>>> design is probably recommended.
>>>>>>>>>>>>
>>>>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>>>>>>>>
>>>>>>>>>>>> We can always come up with socket options but we got to see the value
>>>>>>>>>>>> it would bring since AuriStream don't look that popular among
>>>>>>>>>>>> headsets, at least Ive never seem any device advertising it like
>>>>>>>>>>>> apt-X, etc.
>>>>>>>>>>>
>>>>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>>>>>>>>> that means it is popular enough to be supported...?
>>>>>>>>>>
>>>>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>>>>>>>>> not only I have such device...
>>>>>>>>>>
>>>>>>>>>> So I would really would like to see that kernel finally stops blocking
>>>>>>>>>> usage of this AuriStream codec.
>>>>>>>>>
>>>>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
>>>>>>>>
>>>>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
>>>>>>>> ioctls for retrieving and setting structure with custom parameters:
>>>>>>>>
>>>>>>>> syncPktTypes = 0x003F
>>>>>>>> bandwidth = 4000
>>>>>>>> max_latency = 16
>>>>>>>> voice_settings = 0x63
>>>>>>>> retx_effort = 2
>>>>>>>>
>>>>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
>>>>>>>> for voice settings and moreover it is whitelisted only for two values.
>>>>>>>
>>>>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>>>>>>
>>>>>> Ok. I see that there is another "example" configuration for AuriStream
>>>>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
>>>>>>
>>>>>> So it really is not simple as it can be seen.
>>>>>
>>>>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
>>>>>
>>>>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
>>>>>
>>>>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>>>>
>>>> Ok. I will look at it and I will try to propose how to extend current
>>>> BT_VOICE ioctl API for supporting all those new parameters.
>>>
>>> Below is inline MIME part with POC patch which try to implement a new
>>> IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
>>> settings.
>>>
>>> It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
>>> voice_setting, pkt_type, max_latency, retrans_effort>, but with
>>> maximally 10 array members (due to usage of static array storage). cvsd
>>> codec uses 7 different fallback settings (see voice_setup_cvsd), so for
>>> POC 10 should be enough.
>>>
>>> Because a new IOCL has different members then old BT_VOICE I rather
>>> decided to introduce a new IOCTL and not hacking old IOCTL to accept two
>>> different structures.
>>>
>>> Please let me know what do you think about this API, if this is a way
>>> how to continue or if something different is needed.
>>>
>>> --
>>> Pali Rohár
>>> [email protected]
>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>>> index fabee6db0abb..0e9f4ac07220 100644
>>> --- a/include/net/bluetooth/bluetooth.h
>>> +++ b/include/net/bluetooth/bluetooth.h
>>> @@ -122,6 +122,19 @@ struct bt_voice {
>>> #define BT_SNDMTU 12
>>> #define BT_RCVMTU 13
>>>
>>> +#define BT_VOICE_SETUP 14
>>> +#define BT_VOICE_SETUP_ARRAY_SIZE 10
>>> +struct bt_voice_setup {
>>> + __u8 sco_capable:1;
>>> + __u8 esco_capable:1;
>>> + __u32 tx_bandwidth;
>>> + __u32 rx_bandwidth;
>>> + __u16 voice_setting;
>>> + __u16 pkt_type;
>>> + __u16 max_latency;
>>> + __u8 retrans_effort;
>>> +};
>>> +
>>> __printf(1, 2)
>>> void bt_info(const char *fmt, ...);
>>> __printf(1, 2)
>>> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
>>> index 094e61e07030..8f3c161da1c4 100644
>>> --- a/include/net/bluetooth/hci_core.h
>>> +++ b/include/net/bluetooth/hci_core.h
>>> @@ -477,7 +477,7 @@ struct hci_conn {
>>> __u8 passkey_entered;
>>> __u16 disc_timeout;
>>> __u16 conn_timeout;
>>> - __u16 setting;
>>> + struct bt_voice_setup voice_setup[BT_VOICE_SETUP_ARRAY_SIZE];
>>> __u16 le_conn_min_interval;
>>> __u16 le_conn_max_interval;
>>> __u16 le_conn_interval;
>>> @@ -897,8 +897,8 @@ static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
>>> }
>>>
>>> int hci_disconnect(struct hci_conn *conn, __u8 reason);
>>> -bool hci_setup_sync(struct hci_conn *conn, __u16 handle);
>>> -void hci_sco_setup(struct hci_conn *conn, __u8 status);
>>> +int hci_setup_sync(struct hci_conn *conn, __u16 handle);
>>> +int hci_sco_setup(struct hci_conn *conn, __u8 status);
>>>
>>> struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
>>> u8 role);
>>> @@ -920,7 +920,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
>>> struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
>>> u8 sec_level, u8 auth_type);
>>> struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
>>> - __u16 setting);
>>> + struct bt_voice_setup *voice_setup);
>>> int hci_conn_check_link_mode(struct hci_conn *conn);
>>> int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
>>> int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>>> index bd4978ce8c45..0aa2ad98eb80 100644
>>> --- a/net/bluetooth/hci_conn.c
>>> +++ b/net/bluetooth/hci_conn.c
>>> @@ -35,30 +35,6 @@
>>> #include "smp.h"
>>> #include "a2mp.h"
>>>
>>> -struct sco_param {
>>> - u16 pkt_type;
>>> - u16 max_latency;
>>> - u8 retrans_effort;
>>> -};
>>> -
>>> -static const struct sco_param esco_param_cvsd[] = {
>>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
>>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
>>> - { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
>>> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
>>> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
>>> -};
>>> -
>>> -static const struct sco_param sco_param_cvsd[] = {
>>> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
>>> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
>>> -};
>>> -
>>> -static const struct sco_param esco_param_msbc[] = {
>>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d, 0x02 }, /* T2 */
>>> - { EDR_ESCO_MASK | ESCO_EV3, 0x0008, 0x02 }, /* T1 */
>>> -};
>>> -
>>
>> can you split this into multiple logical patches. And ensure sending it with git send-email.
>
> I just send it as is to know if such API make sense and should I
> continue or not. Preparing patches for git send-email takes a lot of
> time and I wanted to know if such API is OK or should be fully
> rewritten. So I do not spend on something which does not make sense.
> Above patch is not mean to be complete not ready for merge.
What is wrong with git-format-patch? I don’t need much time to prepare patches. Anyway, I going to have a look what is the best way to load these parameter tables into the kernel.
Regards
Marcel
On Wednesday 20 November 2019 00:47:56 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>>>>>>>>> reach PA before we start digging into this.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>>>>>>>>> or any other codec.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>>>>>>>>> design is probably recommended.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>>>>>>>>>
> >>>>>>>>>>>> We can always come up with socket options but we got to see the value
> >>>>>>>>>>>> it would bring since AuriStream don't look that popular among
> >>>>>>>>>>>> headsets, at least Ive never seem any device advertising it like
> >>>>>>>>>>>> apt-X, etc.
> >>>>>>>>>>>
> >>>>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>>>>>>>>> that means it is popular enough to be supported...?
> >>>>>>>>>>
> >>>>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>>>>>>>>> not only I have such device...
> >>>>>>>>>>
> >>>>>>>>>> So I would really would like to see that kernel finally stops blocking
> >>>>>>>>>> usage of this AuriStream codec.
> >>>>>>>>>
> >>>>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> >>>>>>>>
> >>>>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> >>>>>>>> ioctls for retrieving and setting structure with custom parameters:
> >>>>>>>>
> >>>>>>>> syncPktTypes = 0x003F
> >>>>>>>> bandwidth = 4000
> >>>>>>>> max_latency = 16
> >>>>>>>> voice_settings = 0x63
> >>>>>>>> retx_effort = 2
> >>>>>>>>
> >>>>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> >>>>>>>> for voice settings and moreover it is whitelisted only for two values.
> >>>>>>>
> >>>>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> >>>>>>
> >>>>>> Ok. I see that there is another "example" configuration for AuriStream
> >>>>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> >>>>>>
> >>>>>> So it really is not simple as it can be seen.
> >>>>>
> >>>>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> >>>>>
> >>>>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> >>>>>
> >>>>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> >>>>
> >>>> Ok. I will look at it and I will try to propose how to extend current
> >>>> BT_VOICE ioctl API for supporting all those new parameters.
> >>>
> >>> Below is inline MIME part with POC patch which try to implement a new
> >>> IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> >>> settings.
> >>>
> >>> It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> >>> voice_setting, pkt_type, max_latency, retrans_effort>, but with
> >>> maximally 10 array members (due to usage of static array storage). cvsd
> >>> codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> >>> POC 10 should be enough.
> >>>
> >>> Because a new IOCL has different members then old BT_VOICE I rather
> >>> decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> >>> different structures.
> >>>
> >>> Please let me know what do you think about this API, if this is a way
> >>> how to continue or if something different is needed.
> >>>
> >>> --
> >>> Pali Rohár
> >>> [email protected]
> >>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> >>> index fabee6db0abb..0e9f4ac07220 100644
> >>> --- a/include/net/bluetooth/bluetooth.h
> >>> +++ b/include/net/bluetooth/bluetooth.h
> >>> @@ -122,6 +122,19 @@ struct bt_voice {
> >>> #define BT_SNDMTU 12
> >>> #define BT_RCVMTU 13
> >>>
> >>> +#define BT_VOICE_SETUP 14
> >>> +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> >>> +struct bt_voice_setup {
> >>> + __u8 sco_capable:1;
> >>> + __u8 esco_capable:1;
> >>> + __u32 tx_bandwidth;
> >>> + __u32 rx_bandwidth;
> >>> + __u16 voice_setting;
> >>> + __u16 pkt_type;
> >>> + __u16 max_latency;
> >>> + __u8 retrans_effort;
> >>> +};
> >>> +
> >>> __printf(1, 2)
> >>> void bt_info(const char *fmt, ...);
> >>> __printf(1, 2)
> >>> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> >>> index 094e61e07030..8f3c161da1c4 100644
> >>> --- a/include/net/bluetooth/hci_core.h
> >>> +++ b/include/net/bluetooth/hci_core.h
> >>> @@ -477,7 +477,7 @@ struct hci_conn {
> >>> __u8 passkey_entered;
> >>> __u16 disc_timeout;
> >>> __u16 conn_timeout;
> >>> - __u16 setting;
> >>> + struct bt_voice_setup voice_setup[BT_VOICE_SETUP_ARRAY_SIZE];
> >>> __u16 le_conn_min_interval;
> >>> __u16 le_conn_max_interval;
> >>> __u16 le_conn_interval;
> >>> @@ -897,8 +897,8 @@ static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
> >>> }
> >>>
> >>> int hci_disconnect(struct hci_conn *conn, __u8 reason);
> >>> -bool hci_setup_sync(struct hci_conn *conn, __u16 handle);
> >>> -void hci_sco_setup(struct hci_conn *conn, __u8 status);
> >>> +int hci_setup_sync(struct hci_conn *conn, __u16 handle);
> >>> +int hci_sco_setup(struct hci_conn *conn, __u8 status);
> >>>
> >>> struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
> >>> u8 role);
> >>> @@ -920,7 +920,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
> >>> struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
> >>> u8 sec_level, u8 auth_type);
> >>> struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
> >>> - __u16 setting);
> >>> + struct bt_voice_setup *voice_setup);
> >>> int hci_conn_check_link_mode(struct hci_conn *conn);
> >>> int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
> >>> int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
> >>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> >>> index bd4978ce8c45..0aa2ad98eb80 100644
> >>> --- a/net/bluetooth/hci_conn.c
> >>> +++ b/net/bluetooth/hci_conn.c
> >>> @@ -35,30 +35,6 @@
> >>> #include "smp.h"
> >>> #include "a2mp.h"
> >>>
> >>> -struct sco_param {
> >>> - u16 pkt_type;
> >>> - u16 max_latency;
> >>> - u8 retrans_effort;
> >>> -};
> >>> -
> >>> -static const struct sco_param esco_param_cvsd[] = {
> >>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
> >>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
> >>> - { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
> >>> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
> >>> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
> >>> -};
> >>> -
> >>> -static const struct sco_param sco_param_cvsd[] = {
> >>> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
> >>> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
> >>> -};
> >>> -
> >>> -static const struct sco_param esco_param_msbc[] = {
> >>> - { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d, 0x02 }, /* T2 */
> >>> - { EDR_ESCO_MASK | ESCO_EV3, 0x0008, 0x02 }, /* T1 */
> >>> -};
> >>> -
> >>
> >> can you split this into multiple logical patches. And ensure sending it with git send-email.
> >
> > I just send it as is to know if such API make sense and should I
> > continue or not. Preparing patches for git send-email takes a lot of
> > time and I wanted to know if such API is OK or should be fully
> > rewritten. So I do not spend on something which does not make sense.
> > Above patch is not mean to be complete not ready for merge.
>
> What is wrong with git-format-patch? I don’t need much time to prepare patches. Anyway, I going to have a look what is the best way to load these parameter tables into the kernel.
>
> Regards
>
> Marcel
>
I was playing with another suggestion for API:
+#define BT_VOICE_SETUP 14
+struct bt_voice_pkt_type {
+ __u8 capability; /* 0x01 - SCO; 0x02 - eSCO */
+ __u8 retrans_effort;
+ __u16 pkt_type;
+ __u16 max_latency;
+};
+struct bt_voice_setup {
+ __u16 voice_setting;
+ __u16 pkt_types_count;
+ __u32 tx_bandwidth;
+ __u32 rx_bandwidth;
+ struct bt_voice_pkt_type pkt_types[];
+};
So voice_setttings, pkt_types_count and badwidth would not be repeated
as it is same for every pkt_type/retrans_effors/max_latency.
But above uses C99 flexible arrays, so I do not know if API kernel <-->
userspace API is allowed to use C99 flexible arrays.
But getsockopt/setsockopt functions are possible to write with above
API.
--
Pali Rohár
[email protected]
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index fabee6db0abb..29590c6749d5 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -116,12 +116,49 @@ struct bt_voice {
__u16 setting;
};
-#define BT_VOICE_TRANSPARENT 0x0003
-#define BT_VOICE_CVSD_16BIT 0x0060
-
#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;
+};
+#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
+#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
+#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
+#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
+struct bt_voice_setup {
+ __u16 voice_setting;
+ __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
+ __u8 pkt_types_count;
+ __u32 tx_bandwidth;
+ __u32 rx_bandwidth;
+ __u32 input_bandwidth;
+ __u32 output_bandwidth;
+ __u8 tx_coding_format[5];
+ __u8 rx_coding_format[5];
+ __u8 input_coding_format[5];
+ __u8 output_coding_format[5];
+ __u16 tx_codec_frame_size;
+ __u16 rx_codec_frame_size;
+ __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;
+ __u8 input_data_path;
+ __u8 output_data_path;
+ __u8 input_unit_size;
+ __u8 output_unit_size;
+ struct bt_voice_pkt_type pkt_types[];
+};
+
__printf(1, 2)
void bt_info(const char *fmt, ...);
__printf(1, 2)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 094e61e07030..c99236e3a6d2 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -477,7 +477,7 @@ struct hci_conn {
__u8 passkey_entered;
__u16 disc_timeout;
__u16 conn_timeout;
- __u16 setting;
+ const struct bt_voice_setup *voice_setup;
__u16 le_conn_min_interval;
__u16 le_conn_max_interval;
__u16 le_conn_interval;
@@ -897,8 +897,8 @@ static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
}
int hci_disconnect(struct hci_conn *conn, __u8 reason);
-bool hci_setup_sync(struct hci_conn *conn, __u16 handle);
-void hci_sco_setup(struct hci_conn *conn, __u8 status);
+int hci_setup_sync(struct hci_conn *conn, __u16 handle);
+int hci_sco_setup(struct hci_conn *conn, __u8 status);
struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
u8 role);
@@ -920,7 +920,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
u8 sec_level, u8 auth_type);
struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
- __u16 setting);
+ const struct bt_voice_setup *voice_setup);
int hci_conn_check_link_mode(struct hci_conn *conn);
int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
@@ -1164,6 +1164,9 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
#define lmp_lsto_capable(dev) ((dev)->features[0][7] & LMP_LSTO)
#define lmp_inq_tx_pwr_capable(dev) ((dev)->features[0][7] & LMP_INQ_TX_PWR)
#define lmp_ext_feat_capable(dev) ((dev)->features[0][7] & LMP_EXTFEATURES)
+#define lmp_ulaw_capable(dev) ((dev)->features[0][1] & LMP_ULAW)
+#define lmp_alaw_capable(dev) ((dev)->features[0][1] & LMP_ALAW)
+#define lmp_cvsd_capable(dev) ((dev)->features[0][2] & LMP_CVSD)
#define lmp_transp_capable(dev) ((dev)->features[0][2] & LMP_TRANSPARENT)
#define lmp_edr_2m_capable(dev) ((dev)->features[0][3] & LMP_EDR_2M)
#define lmp_edr_3m_capable(dev) ((dev)->features[0][3] & LMP_EDR_3M)
@@ -1592,6 +1595,15 @@ void hci_copy_identity_address(struct hci_dev *hdev, bdaddr_t *bdaddr,
#define SCO_AIRMODE_MASK 0x0003
#define SCO_AIRMODE_CVSD 0x0000
+#define SCO_AIRMODE_ULAW 0x0001
+#define SCO_AIRMODE_ALAW 0x0002
#define SCO_AIRMODE_TRANSP 0x0003
+#define lmp_voice_setting_compatible(dev, voice_setting) ( \
+ (((voice_setting) & SCO_AIRMODE_MASK) == SCO_AIRMODE_CVSD) ? lmp_cvsd_capable(dev) : \
+ (((voice_setting) & SCO_AIRMODE_MASK) == SCO_AIRMODE_ULAW) ? lmp_ulaw_capable(dev) : \
+ (((voice_setting) & SCO_AIRMODE_MASK) == SCO_AIRMODE_ALAW) ? lmp_alaw_capable(dev) : \
+ (((voice_setting) & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP) ? lmp_transp_capable(dev) : \
+ false)
+
#endif /* __HCI_CORE_H */
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index bd4978ce8c45..ac0e3aceac01 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -35,30 +35,6 @@
#include "smp.h"
#include "a2mp.h"
-struct sco_param {
- u16 pkt_type;
- u16 max_latency;
- u8 retrans_effort;
-};
-
-static const struct sco_param esco_param_cvsd[] = {
- { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
- { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
- { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
- { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
- { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
-};
-
-static const struct sco_param sco_param_cvsd[] = {
- { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
- { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
-};
-
-static const struct sco_param esco_param_msbc[] = {
- { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d, 0x02 }, /* T2 */
- { EDR_ESCO_MASK | ESCO_EV3, 0x0008, 0x02 }, /* T1 */
-};
-
/* This function requires the caller holds hdev->lock */
static void hci_connect_le_scan_cleanup(struct hci_conn *conn)
{
@@ -250,7 +226,7 @@ int hci_disconnect(struct hci_conn *conn, __u8 reason)
return hci_abort_conn(conn, reason);
}
-static void hci_add_sco(struct hci_conn *conn, __u16 handle)
+static int hci_add_sco(struct hci_conn *conn, __u16 handle)
{
struct hci_dev *hdev = conn->hdev;
struct hci_cp_add_sco cp;
@@ -262,17 +238,21 @@ static void hci_add_sco(struct hci_conn *conn, __u16 handle)
conn->attempt++;
+ if (conn->voice_setup->voice_setting != hdev->voice_setting)
+ return -EOPNOTSUPP;
+
cp.handle = cpu_to_le16(handle);
cp.pkt_type = cpu_to_le16(conn->pkt_type);
- hci_send_cmd(hdev, HCI_OP_ADD_SCO, sizeof(cp), &cp);
+ return hci_send_cmd(hdev, HCI_OP_ADD_SCO, sizeof(cp), &cp);
}
-bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
+int hci_setup_sync(struct hci_conn *conn, __u16 handle)
{
struct hci_dev *hdev = conn->hdev;
struct hci_cp_setup_sync_conn cp;
- const struct sco_param *param;
+ const struct bt_voice_setup *voice_setup = conn->voice_setup;
+ unsigned int i, j;
BT_DBG("hcon %p", conn);
@@ -281,41 +261,26 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
conn->attempt++;
- cp.handle = cpu_to_le16(handle);
-
- cp.tx_bandwidth = cpu_to_le32(0x00001f40);
- cp.rx_bandwidth = cpu_to_le32(0x00001f40);
- cp.voice_setting = cpu_to_le16(conn->setting);
-
- switch (conn->setting & SCO_AIRMODE_MASK) {
- case SCO_AIRMODE_TRANSP:
- if (conn->attempt > ARRAY_SIZE(esco_param_msbc))
- return false;
- param = &esco_param_msbc[conn->attempt - 1];
- break;
- case SCO_AIRMODE_CVSD:
- if (lmp_esco_capable(conn->link)) {
- if (conn->attempt > ARRAY_SIZE(esco_param_cvsd))
- return false;
- param = &esco_param_cvsd[conn->attempt - 1];
- } else {
- if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
- return false;
- param = &sco_param_cvsd[conn->attempt - 1];
- }
- break;
- default:
- return false;
+ for (j = 0, i = 0; i < voice_setup->pkt_types_count && j < conn->attempt; i++) {
+ if (conn->type == ESCO_LINK && !(voice_setup->pkt_types[i].capability & BT_VOICE_PKT_TYPE_CAP_ESCO))
+ continue;
+ if (conn->type == SCO_LINK && !(voice_setup->pkt_types[i].capability & BT_VOICE_PKT_TYPE_CAP_SCO))
+ continue;
+ j++;
}
- cp.retrans_effort = param->retrans_effort;
- cp.pkt_type = __cpu_to_le16(param->pkt_type);
- cp.max_latency = __cpu_to_le16(param->max_latency);
+ if (j != conn->attempt)
+ return -EINVAL;
- if (hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp) < 0)
- return false;
+ cp.handle = cpu_to_le16(handle);
+ cp.tx_bandwidth = cpu_to_le32(voice_setup->tx_bandwidth);
+ cp.rx_bandwidth = cpu_to_le32(voice_setup->rx_bandwidth);
+ cp.voice_setting = cpu_to_le16(voice_setup->voice_setting);
+ cp.pkt_type = cpu_to_le16(voice_setup->pkt_types[j-1].pkt_type);
+ cp.max_latency = cpu_to_le16(voice_setup->pkt_types[j-1].max_latency);
+ cp.retrans_effort = voice_setup->pkt_types[j-1].retrans_effort;
- return true;
+ return hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
u8 hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
@@ -373,24 +338,38 @@ void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __le64 rand,
}
/* Device _must_ be locked */
-void hci_sco_setup(struct hci_conn *conn, __u8 status)
+int hci_sco_setup(struct hci_conn *conn, __u8 status)
{
struct hci_conn *sco = conn->link;
+ int err = 0;
if (!sco)
- return;
+ return -EINVAL;
BT_DBG("hcon %p", conn);
if (!status) {
- if (lmp_esco_capable(conn->hdev))
- hci_setup_sync(sco, conn->handle);
+ bool can_use_add_sco = !(conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || (conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_ADD_SCO);
+ bool can_use_setup_sco = lmp_esco_capable(conn->hdev) && (!(conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || (conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_SETUP_SCO));
+ bool can_use_enh_setup_sco = false /* (conn->hdev->commands[29] & BIT(3)) && (!(conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || (conn->voice_setup->features & BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO)) */ ; /* FIXME: Enhanced Setup Synchronous Connection is unimplemented */
+ if (!lmp_voice_setting_compatible(conn->hdev, conn->voice_setup->voice_setting))
+ err = -EOPNOTSUPP;
+#if 0
+ else if (can_use_enh_setup_sco)
+ err = hci_enh_setup_sync(sco, conn->handle); /* TODO */
+#endif
+ else if (can_use_setup_sco)
+ err = hci_setup_sync(sco, conn->handle);
+ else if (can_use_add_sco)
+ err = hci_add_sco(sco, conn->handle);
else
- hci_add_sco(sco, conn->handle);
+ err = -EOPNOTSUPP;
} else {
hci_connect_cfm(sco, status);
hci_conn_del(sco);
}
+
+ return err;
}
static void hci_conn_timeout(struct work_struct *work)
@@ -1214,10 +1193,11 @@ struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
}
struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
- __u16 setting)
+ const struct bt_voice_setup *voice_setup)
{
struct hci_conn *acl;
struct hci_conn *sco;
+ int err;
acl = hci_connect_acl(hdev, dst, BT_SECURITY_LOW, HCI_AT_NO_BONDING);
if (IS_ERR(acl))
@@ -1237,7 +1217,7 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
hci_conn_hold(sco);
- sco->setting = setting;
+ sco->voice_setup = voice_setup;
if (acl->state == BT_CONNECTED &&
(sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
@@ -1250,7 +1230,11 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
return sco;
}
- hci_sco_setup(acl, 0x00);
+ err = hci_sco_setup(acl, 0x00);
+ if (err) {
+ hci_conn_drop(sco);
+ return ERR_PTR(err);
+ }
}
return sco;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 609fd6871c5a..2e7156bcabc3 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2601,6 +2601,7 @@ static void hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
bacpy(&cp.bdaddr, &ev->bdaddr);
cp.pkt_type = cpu_to_le16(conn->pkt_type);
+ /* FIXME: use voice_setup */
cp.tx_bandwidth = cpu_to_le32(0x00001f40);
cp.rx_bandwidth = cpu_to_le32(0x00001f40);
cp.max_latency = cpu_to_le16(0xffff);
@@ -4137,7 +4138,7 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
if (conn->out) {
conn->pkt_type = (hdev->esco_type & SCO_ESCO_MASK) |
(hdev->esco_type & EDR_ESCO_MASK);
- if (hci_setup_sync(conn, conn->link->handle))
+ if (hci_setup_sync(conn, conn->link->handle) == 0)
goto unlock;
}
/* fall through */
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index ca73d36cc149..7d8443d7e30e 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -2205,6 +2205,16 @@ void __hci_abort_conn(struct hci_request *req, struct hci_conn *conn,
*/
rej.reason = HCI_ERROR_REJ_LIMITED_RESOURCES;
+ if (!lmp_esco_capable(conn->hdev)) {
+ /* If HCI_OP_REJECT_SYNC_CONN_REQ is not supported then use HCI_OP_REJECT_CONN_REQ */
+ struct hci_cp_reject_conn_req rej2;
+ bacpy(&rej2.bdaddr, &rej.bdaddr);
+ rej2.reason = rej.reason;
+ hci_req_add(req, HCI_OP_REJECT_CONN_REQ,
+ sizeof(rej2), &rej2);
+ break;
+ }
+
hci_req_add(req, HCI_OP_REJECT_SYNC_CONN_REQ,
sizeof(rej), &rej);
}
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 9a580999ca57..a3c5cae7a2a2 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -33,6 +33,39 @@
#include <net/bluetooth/hci_core.h>
#include <net/bluetooth/sco.h>
+static const struct bt_voice_setup voice_setup_cvsd = {
+ .features = BT_VOICE_SETUP_FEATURE_CONFIG | BT_VOICE_SETUP_FEATURE_ADD_SCO | BT_VOICE_SETUP_FEATURE_SETUP_SCO,
+ /* TODO: Add configuration for BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO */
+ .voice_setting = 0x0060,
+ .tx_bandwidth = 8000,
+ .rx_bandwidth = 8000,
+ .pkt_types_count = 7,
+ .pkt_types = {
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x01, EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a }, /* S3 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x01, EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007 }, /* S2 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x01, EDR_ESCO_MASK | ESCO_EV3, 0x0007 }, /* S1 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x01, EDR_ESCO_MASK | ESCO_HV3, 0xffff }, /* D1 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0x01, EDR_ESCO_MASK | ESCO_HV1, 0xffff }, /* D0 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0xff, EDR_ESCO_MASK | ESCO_HV3, 0xffff }, /* D1 */
+ { BT_VOICE_PKT_TYPE_CAP_ESCO, 0xff, EDR_ESCO_MASK | ESCO_HV1, 0xffff }, /* D0 */
+ { BT_VOICE_PKT_TYPE_CAP_SCO, 0xff, EDR_ESCO_MASK | ESCO_HV3, 0xffff }, /* D1 */
+ { BT_VOICE_PKT_TYPE_CAP_SCO, 0xff, EDR_ESCO_MASK | ESCO_HV1, 0xffff }, /* D0 */
+ },
+};
+
+static const struct bt_voice_setup voice_setup_msbc = {
+ .features = BT_VOICE_SETUP_FEATURE_CONFIG | BT_VOICE_SETUP_FEATURE_SETUP_SCO,
+ /* TODO: Add configuration for BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO */
+ .voice_setting = 0x0003,
+ .tx_bandwidth = 8000,
+ .rx_bandwidth = 8000,
+ .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 */
+ },
+};
+
static bool disable_esco;
static const struct proto_ops sco_sock_ops;
@@ -65,8 +98,8 @@ struct sco_pinfo {
bdaddr_t src;
bdaddr_t dst;
__u32 flags;
- __u16 setting;
struct sco_conn *conn;
+ struct bt_voice_setup *voice_setup;
};
/* ---- SCO timers ---- */
@@ -231,14 +264,31 @@ static int sco_connect(struct sock *sk)
else
type = SCO_LINK;
- if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
- (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
- err = -EOPNOTSUPP;
- goto done;
+ /* If setsockopt BT_VOICE_SETUP was not called or called without additional features then use default parameters from CVSD or mSBC codec based on voice_setting */
+ if (!sco_pi(sk)->voice_setup || !(sco_pi(sk)->voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || !sco_pi(sk)->voice_setup->pkt_types_count) {
+ /* If setsockopt BT_VOICE or BT_VOICE_SETUP was not called then use global voice_setting */
+ __u16 voice_setting = sco_pi(sk)->voice_setup ? sco_pi(sk)->voice_setup->voice_setting : hdev->voice_setting;
+ const struct bt_voice_setup *source_voice_setup = ((voice_setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP) ? &voice_setup_msbc : &voice_setup_cvsd;
+ size_t voice_setup_size = sizeof(struct bt_voice_setup) + sizeof(struct bt_voice_pkt_type)*source_voice_setup->pkt_types_count;
+ bool set_only_pkt_types = (sco_pi(sk)->voice_setup && (sco_pi(sk)->voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG));
+ struct bt_voice_setup *new_voice_setup = krealloc(sco_pi(sk)->voice_setup, voice_setup_size, GFP_KERNEL);
+ if (!new_voice_setup) {
+ err = -ENOMEM;
+ goto done;
+ }
+ sco_pi(sk)->voice_setup = new_voice_setup;
+ if (set_only_pkt_types) {
+ sco_pi(sk)->voice_setup->pkt_types_count = source_voice_setup->pkt_types_count;
+ memcpy(sco_pi(sk)->voice_setup->pkt_types, source_voice_setup->pkt_types, sizeof(struct bt_voice_pkt_type)*source_voice_setup->pkt_types_count);
+ } else {
+ memcpy(sco_pi(sk)->voice_setup, source_voice_setup, voice_setup_size);
+ memcpy(sco_pi(sk)->voice_setup, source_voice_setup, voice_setup_size);
+ sco_pi(sk)->voice_setup->voice_setting = voice_setting;
+ }
}
hcon = hci_connect_sco(hdev, type, &sco_pi(sk)->dst,
- sco_pi(sk)->setting);
+ sco_pi(sk)->voice_setup);
if (IS_ERR(hcon)) {
err = PTR_ERR(hcon);
goto done;
@@ -368,6 +418,7 @@ static void sco_sock_destruct(struct sock *sk)
{
BT_DBG("sk %p", sk);
+ kfree(sco_pi(sk)->voice_setup);
skb_queue_purge(&sk->sk_receive_queue);
skb_queue_purge(&sk->sk_write_queue);
}
@@ -486,8 +537,6 @@ static struct sock *sco_sock_alloc(struct net *net, struct socket *sock,
sk->sk_protocol = proto;
sk->sk_state = BT_OPEN;
- sco_pi(sk)->setting = BT_VOICE_CVSD_16BIT;
-
timer_setup(&sk->sk_timer, sco_sock_timeout, 0);
bt_sock_link(&sco_sk_list, sk);
@@ -724,47 +773,100 @@ static int sco_sock_sendmsg(struct socket *sock, struct msghdr *msg,
return err;
}
-static void sco_conn_defer_accept(struct hci_conn *conn, u16 setting)
+static void sco_conn_defer_accept(struct hci_conn *conn, const struct bt_voice_setup *voice_setup)
{
struct hci_dev *hdev = conn->hdev;
+ bool can_use_add_sco = !(voice_setup && (voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG)) || (voice_setup->features & BT_VOICE_SETUP_FEATURE_ADD_SCO);
+ bool can_use_setup_sco = lmp_esco_capable(hdev) && (!voice_setup || !(voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || (voice_setup->features & BT_VOICE_SETUP_FEATURE_SETUP_SCO));
+ bool can_use_enh_setup_sco = false /* (hdev->commands[29] & BIT(4)) && (!voice_setup || !(voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) || (voice_setup->features & BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO)) */ ; /* FIXME: Enhanced Setup Synchronous Connection is unimplemented */
BT_DBG("conn %p", conn);
conn->state = BT_CONFIG;
- if (!lmp_esco_capable(hdev)) {
+ if (voice_setup && !lmp_voice_setting_compatible(hdev, voice_setup->voice_setting)) {
+ /* TODO: Throw error about incompatible setup for accept() */
+ }
+
+ if (conn->type == ESCO_LINK && disable_esco) {
+ /* TODO: Throw error about incompatible setup for accept() */
+ }
+
+ if (can_use_add_sco && !can_use_setup_sco && !can_use_enh_setup_sco) {
struct hci_cp_accept_conn_req cp;
+ if (voice_setup && (voice_setup->voice_setting != hdev->voice_setting)) {
+ /* TODO: Throw error about incompatible setup for accept() */
+ }
+
bacpy(&cp.bdaddr, &conn->dst);
cp.role = 0x00; /* Ignored */
hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp);
- } else {
+ } else if (can_use_setup_sco && !can_use_enh_setup_sco) {
struct hci_cp_accept_sync_conn_req cp;
+ const struct bt_voice_pkt_type *pkt_types;
+ unsigned int i, pkt_type_next, pkt_types_count;
bacpy(&cp.bdaddr, &conn->dst);
cp.pkt_type = cpu_to_le16(conn->pkt_type);
- cp.tx_bandwidth = cpu_to_le32(0x00001f40);
- cp.rx_bandwidth = cpu_to_le32(0x00001f40);
- cp.content_format = cpu_to_le16(setting);
-
- switch (setting & SCO_AIRMODE_MASK) {
- case SCO_AIRMODE_TRANSP:
- if (conn->pkt_type & ESCO_2EV3)
- cp.max_latency = cpu_to_le16(0x0008);
+ if (!voice_setup) {
+ cp.content_format = cpu_to_le16(hdev->voice_setting);
+ if ((hdev->voice_setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP)
+ voice_setup = &voice_setup_msbc;
else
- cp.max_latency = cpu_to_le16(0x000D);
- cp.retrans_effort = 0x02;
- break;
- case SCO_AIRMODE_CVSD:
- cp.max_latency = cpu_to_le16(0xffff);
- cp.retrans_effort = 0xff;
+ voice_setup = &voice_setup_cvsd;
+ } else {
+ cp.content_format = cpu_to_le16(voice_setup->voice_setting);
+ }
+
+ if (voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) {
+ cp.tx_bandwidth = cpu_to_le32(voice_setup->tx_bandwidth);
+ cp.rx_bandwidth = cpu_to_le32(voice_setup->rx_bandwidth);
+ } else if ((voice_setup->voice_setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP) {
+ cp.tx_bandwidth = cpu_to_le32(voice_setup_msbc.tx_bandwidth);
+ cp.rx_bandwidth = cpu_to_le32(voice_setup_msbc.rx_bandwidth);
+ } else {
+ cp.tx_bandwidth = cpu_to_le32(voice_setup_cvsd.tx_bandwidth);
+ cp.rx_bandwidth = cpu_to_le32(voice_setup_cvsd.rx_bandwidth);
+ }
+
+ if ((voice_setup->features & BT_VOICE_SETUP_FEATURE_CONFIG) && voice_setup->pkt_types_count) {
+ pkt_types = voice_setup->pkt_types;
+ pkt_types_count = voice_setup->pkt_types_count;
+ } else if ((voice_setup->voice_setting & SCO_AIRMODE_MASK) == SCO_AIRMODE_TRANSP) {
+ pkt_types = voice_setup_msbc.pkt_types;
+ pkt_types_count = voice_setup_msbc.pkt_types_count;
+ } else {
+ pkt_types = voice_setup_cvsd.pkt_types;
+ pkt_types_count = voice_setup_cvsd.pkt_types_count;
+ }
+
+ for (pkt_type_next = 0, i = 0; i < pkt_types_count; ++i) {
+ if (conn->type == ESCO_LINK && !(pkt_types[i].capability & BT_VOICE_PKT_TYPE_CAP_ESCO))
+ continue;
+ if (conn->type == SCO_LINK && !(pkt_types[i].capability & BT_VOICE_PKT_TYPE_CAP_SCO))
+ continue;
+ if (!pkt_type_next)
+ pkt_type_next = i;
+ if (!(pkt_types[i].pkt_type & conn->pkt_type))
+ continue;
break;
}
+ if (i == pkt_types_count)
+ i = pkt_type_next;
+
+ cp.max_latency = cpu_to_le16(pkt_types[i].max_latency);
+ cp.retrans_effort = pkt_types[i].retrans_effort;
+
hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ,
sizeof(cp), &cp);
+ } else if (can_use_enh_setup_sco) {
+ /* TODO */
+ } else {
+ /* TODO: Throw error about incompatible setup for accept() */
}
}
@@ -778,9 +880,7 @@ static int sco_sock_recvmsg(struct socket *sock, struct msghdr *msg,
if (sk->sk_state == BT_CONNECT2 &&
test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
- sco_conn_defer_accept(pi->conn->hcon, pi->setting);
- sk->sk_state = BT_CONFIG;
-
+ sco_conn_defer_accept(pi->conn->hcon, pi->voice_setup);
release_sock(sk);
return 0;
}
@@ -794,8 +894,10 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, unsigned int optlen)
{
struct sock *sk = sock->sk;
- int len, err = 0;
+ int err = 0;
struct bt_voice voice;
+ char buffer[1536]; /* FIXME: max size */
+ struct bt_voice_setup *new_voice_setup;
u32 opt;
BT_DBG("sk %p", sk);
@@ -828,22 +930,62 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname,
break;
}
- voice.setting = sco_pi(sk)->setting;
+ if (optlen != sizeof(voice)) {
+ err = -EINVAL;
+ break;
+ }
- len = min_t(unsigned int, sizeof(voice), optlen);
- if (copy_from_user((char *)&voice, optval, len)) {
+ if (copy_from_user((char *)&voice, optval, optlen)) {
err = -EFAULT;
break;
}
- /* Explicitly check for these values */
- if (voice.setting != BT_VOICE_TRANSPARENT &&
- voice.setting != BT_VOICE_CVSD_16BIT) {
+ if (!sco_pi(sk)->voice_setup) {
+ sco_pi(sk)->voice_setup = kzalloc(sizeof(struct bt_voice_setup), GFP_KERNEL);
+ if (!sco_pi(sk)->voice_setup) {
+ err = -ENOMEM;
+ break;
+ }
+ }
+
+ sco_pi(sk)->voice_setup->voice_setting = voice.setting;
+
+ break;
+
+ case BT_VOICE_SETUP:
+ if (sk->sk_state != BT_OPEN && sk->sk_state != BT_BOUND &&
+ sk->sk_state != BT_CONNECT2) {
+ err = -EINVAL;
+ break;
+ }
+
+ /* FIXME: max size limit */
+ if (optlen < sizeof(struct bt_voice_setup) || (optlen-sizeof(struct bt_voice_setup)) % sizeof(struct bt_voice_pkt_type) != 0 || optlen > sizeof(buffer)) {
+ err = -EINVAL;
+ break;
+ }
+
+ if (copy_from_user((char *)&buffer, optval, optlen)) {
+ err = -EFAULT;
+ break;
+ }
+
+ if (((struct bt_voice_setup *)&buffer)->pkt_types_count > (optlen - sizeof(struct bt_voice_setup)) / sizeof(struct bt_voice_pkt_type)) {
err = -EINVAL;
break;
}
- sco_pi(sk)->setting = voice.setting;
+ /* FIXME: should we check if disable_esco is set and in voice_setup is at least one BT_VOICE_PKT_TYPE_CAP_SCO pkt_type? */
+
+ new_voice_setup = krealloc(sco_pi(sk)->voice_setup, optlen, GFP_KERNEL);
+ if (!new_voice_setup) {
+ err = -ENOMEM;
+ break;
+ }
+
+ memcpy(new_voice_setup, &buffer, optlen);
+ sco_pi(sk)->voice_setup = new_voice_setup;
+
break;
default:
@@ -948,7 +1090,13 @@ static int sco_sock_getsockopt(struct socket *sock, int level, int optname,
break;
case BT_VOICE:
- voice.setting = sco_pi(sk)->setting;
+ /* When voice setting were not set then due to backward compatibility return something: either voice settings (if are available) or fallback to CVSD voice setting */
+ if (sco_pi(sk)->voice_setup)
+ voice.setting = sco_pi(sk)->voice_setup->voice_setting;
+ else if (sco_pi(sk)->conn)
+ voice.setting = sco_pi(sk)->conn->hcon->hdev->voice_setting;
+ else
+ voice.setting = voice_setup_cvsd.voice_setting;
len = min_t(unsigned int, len, sizeof(voice));
if (copy_to_user(optval, (char *)&voice, len))
@@ -956,6 +1104,24 @@ static int sco_sock_getsockopt(struct socket *sock, int level, int optname,
break;
+ case BT_VOICE_SETUP:
+ if (sco_pi(sk)->voice_setup) {
+ len = min_t(unsigned int, len, sizeof(struct bt_voice_setup) + sizeof(struct bt_voice_pkt_type)*sco_pi(sk)->voice_setup->pkt_types_count);
+ if (copy_to_user(optval, (char *)sco_pi(sk)->voice_setup, len)) {
+ err = -EFAULT;
+ break;
+ }
+ } else {
+ len = 0;
+ }
+
+ if (put_user(len, optlen)) {
+ err = -EFAULT;
+ break;
+ }
+
+ break;
+
default:
err = -ENOPROTOOPT;
break;
On Wednesday 13 November 2019 10:22:56 Pali Rohár wrote:
> On Tuesday 12 November 2019 22:06:33 Pavel Machek wrote:
> > Hi!
> >
> > > > > >>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> > > > > >>>>>>>> below and currently kernel does not support it. This is why I'm asking
> > > > > >>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> > > > > >>>>>>>
> > > > > >>>>>>> We can always come up with socket options but we got to see the value
> > > > > >>>>>>> it would bring since AuriStream don't look that popular among
> > > > > >>>>>>> headsets, at least Ive never seem any device advertising it like
> > > > > >>>>>>> apt-X, etc.
> > > > > >>>>>>
> > > > > >>>>>> Pali clearly has such device and he is willing to work on it. Surely
> > > > > >>>>>> that means it is popular enough to be supported...?
> > > > > >>>>>
> > > > > >>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> > > > > >>>>> not only I have such device...
> > > > > >>>>>
> > > > > >>>>> So I would really would like to see that kernel finally stops blocking
> > > > > >>>>> usage of this AuriStream codec.
> > > > > >>>>
> > > > > >>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> > > > > >>>
> > > > > >>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> > > > > >>> ioctls for retrieving and setting structure with custom parameters:
> > > > > >>>
> > > > > >>> syncPktTypes = 0x003F
> > > > > >>> bandwidth = 4000
> > > > > >>> max_latency = 16
> > > > > >>> voice_settings = 0x63
> > > > > >>> retx_effort = 2
> > > > > >>>
> > > > > >>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > > > > >>> for voice settings and moreover it is whitelisted only for two values.
> > > > > >>
> > > > > >> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> > > > > >
> > > > > > Ok. I see that there is another "example" configuration for AuriStream
> > > > > > with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> > > > > >
> > > > > > So it really is not simple as it can be seen.
> > > > >
> > > > > currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> > > > >
> > > > > So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> > > > >
> > > > > My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> > > >
> > > > Ok. I will look at it and I will try to propose how to extend current
> > > > BT_VOICE ioctl API for supporting all those new parameters.
> > >
> > > Below is inline MIME part with POC patch which try to implement a new
> > > IOCTL (currently named BT_VOICE_SETUP) for configuring voice sco
> > > settings.
> > >
> > > It uses flexible array of parameters <tx_bandwidth, rx_bandwidth,
> > > voice_setting, pkt_type, max_latency, retrans_effort>, but with
> > > maximally 10 array members (due to usage of static array storage). cvsd
> > > codec uses 7 different fallback settings (see voice_setup_cvsd), so for
> > > POC 10 should be enough.
> > >
> > > Because a new IOCL has different members then old BT_VOICE I rather
> > > decided to introduce a new IOCTL and not hacking old IOCTL to accept two
> > > different structures.
> > >
> > > Please let me know what do you think about this API, if this is a way
> > > how to continue or if something different is needed.
> >
> >
> > New ioctl sounds like good idea.
> >
> > > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > > index fabee6db0abb..0e9f4ac07220 100644
> > > --- a/include/net/bluetooth/bluetooth.h
> > > +++ b/include/net/bluetooth/bluetooth.h
> > > @@ -122,6 +122,19 @@ struct bt_voice {
> > > #define BT_SNDMTU 12
> > > #define BT_RCVMTU 13
> > >
> > > +#define BT_VOICE_SETUP 14
> > > +#define BT_VOICE_SETUP_ARRAY_SIZE 10
> > > +struct bt_voice_setup {
> > > + __u8 sco_capable:1;
> > > + __u8 esco_capable:1;
> > > + __u32 tx_bandwidth;
> > > + __u32 rx_bandwidth;
> > > + __u16 voice_setting;
> > > + __u16 pkt_type;
> > > + __u16 max_latency;
> > > + __u8 retrans_effort;
> > > +};
> > > +
> >
> > Is this the new ioctl? I'd assume it should go to include/user/..
> > somewhere to be exported to userspace...?
>
> I put it into same file where is structure for old ioctl BT_VOICE.
Userspace headers are provided by bluez project. So once this API would
be in kernel, bluez headers needs to be extended.
> > Is it good idea to use __u8 :1 in user<->kernel API?
>
> I do not know. Should it be rather (C99) bool? Or just one __u8?
In next proposed API I used one __u8 with bitmask macros. So there are
no :1 anymore.
--
Pali Rohár
[email protected]
On Thursday 18 July 2019 22:06:03 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>>>>>> reach PA before we start digging into this.
> >>>>>>>>>>
> >>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>>>>>> or any other codec.
> >>>>>>>>>
> >>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>>>>>> design is probably recommended.
> >>>>>>>>>
> >>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>>>>>>
> >>>>>>>>> We can always come up with socket options but we got to see the value
> >>>>>>>>> it would bring since AuriStream don't look that popular among
> >>>>>>>>> headsets, at least Ive never seem any device advertising it like
> >>>>>>>>> apt-X, etc.
> >>>>>>>>
> >>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>>>>>> that means it is popular enough to be supported...?
> >>>>>>>
> >>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>>>>>> not only I have such device...
> >>>>>>>
> >>>>>>> So I would really would like to see that kernel finally stops blocking
> >>>>>>> usage of this AuriStream codec.
> >>>>>>
> >>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
> >>>>>
> >>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
> >>>>> ioctls for retrieving and setting structure with custom parameters:
> >>>>>
> >>>>> syncPktTypes = 0x003F
> >>>>> bandwidth = 4000
> >>>>> max_latency = 16
> >>>>> voice_settings = 0x63
> >>>>> retx_effort = 2
> >>>>>
> >>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
> >>>>> for voice settings and moreover it is whitelisted only for two values.
> >>>>
> >>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
> >>>
> >>> Ok. I see that there is another "example" configuration for AuriStream
> >>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
> >>>
> >>> So it really is not simple as it can be seen.
> >>
> >> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
> >>
> >> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
> >>
> >> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
> >
> > Ok. I will look at it and I will try to propose how to extend current
> > BT_VOICE ioctl API for supporting all those new parameters.
> >
> >>>>>> We have kept is really simple since there was only CVSD and mSBC as of now.
> >>>>>
> >>>>> Seems that custom codecs are already widely used, so it would be great
> >>>>> it Linux kernel allows to use also other codecs in future without need
> >>>>> to explicitly whitelist them.
> >>>>
> >>>> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
> >>>
> >>> CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
> >>> codecs but I have not seen it used. Has somebody tried to implement it?
> >>> I think just replacing voice_settings should be enough as encoding /
> >>> decoding should be done in bluetooth firmware / hardware.
> >>>
> >>> And then there is AuriStream which based on google results it supported
> >>> by lot of headsets.
> >>>
> >>> So at least 3 different codecs are widely supported by headset.
> >>
> >> The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream.
> >
> > More interesting question would be if alaw codec can be used in
> > transparent mode by transmitter and in "normal alaw" mode by receiver.
> > So it is possible to "tell" bluetooth chip "hey, I have already prepared
> > alaw or CVSD packets for you”?
>
> actually alaw is an over the air codec. Using it in transparent mode has no profile support. So while possible, it is not interoperable.
I'm looking at Voice Setting parameters and it is possible to set Input
Coding Format to alaw and also Air Coding Format to alaw. It is not
Transparent Air mode, so above problem with profile interoperability
does not have to be there. So in theory it should be possible to
configure bluetooth chip to pass-thru alaw data without re-encoding
them. So after new API for "unlocking" other non-whitelisted Voice
Settings is there, this can start to be tested...
Apparently there is no CVSD Input Coding Format in Voice Setting, so
CVSD codec data cannot be pass-thru to bt chip via existing Setup
Synchronous Connection. But there is Enhanced Setup Synchronous
Connection command which does not use Voice Setting structure which
seems to be more powerfull in codec handling.
> > In Europe all landline phones (and also their SIP non-compressed
> > equivalents) use alaw codec. So ability to pass SIP alaw samples
> > directly to headset could increase quality of SIP calls. As currently
> > received alaw samples are converted to linear PCM, then send to
> > bluetooth chip which converts it into CVSD codec and finally bluetooth
> > headset converts CVSD to analog.
>
> Nice idea, but not worth the effort.
>
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>>>>>> to be honest, I would rather see WBS implementation finally
>>>>>>>>>>>>> reach PA before we start digging into this.
>>>>>>>>>>>>
>>>>>>>>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
>>>>>>>>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
>>>>>>>>>>>> extensible design. So the aim is that adding new codec would be very
>>>>>>>>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
>>>>>>>>>>>> or any other codec.
>>>>>>>>>>>
>>>>>>>>>>> Well HSP don't have support for codec negotiation, but yes a modular
>>>>>>>>>>> design is probably recommended.
>>>>>>>>>>>
>>>>>>>>>>>> But for AuriStream I need to set custom SCO parameters as described
>>>>>>>>>>>> below and currently kernel does not support it. This is why I'm asking
>>>>>>>>>>>> how kernel can export for userspace configuration of SCO parameters...
>>>>>>>>>>>
>>>>>>>>>>> We can always come up with socket options but we got to see the value
>>>>>>>>>>> it would bring since AuriStream don't look that popular among
>>>>>>>>>>> headsets, at least Ive never seem any device advertising it like
>>>>>>>>>>> apt-X, etc.
>>>>>>>>>>
>>>>>>>>>> Pali clearly has such device and he is willing to work on it. Surely
>>>>>>>>>> that means it is popular enough to be supported...?
>>>>>>>>>
>>>>>>>>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
>>>>>>>>> not only I have such device...
>>>>>>>>>
>>>>>>>>> So I would really would like to see that kernel finally stops blocking
>>>>>>>>> usage of this AuriStream codec.
>>>>>>>>
>>>>>>>> we need to figure out on how we do the kernel API to allow you this specific setting.
>>>>>>>
>>>>>>> Hi Marcel! Kernel API for userspace should be simple. Just add two
>>>>>>> ioctls for retrieving and setting structure with custom parameters:
>>>>>>>
>>>>>>> syncPktTypes = 0x003F
>>>>>>> bandwidth = 4000
>>>>>>> max_latency = 16
>>>>>>> voice_settings = 0x63
>>>>>>> retx_effort = 2
>>>>>>>
>>>>>>> Or add more ioctls, one ioctl per parameter. There is already only ioctl
>>>>>>> for voice settings and moreover it is whitelisted only for two values.
>>>>>>
>>>>>> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.
>>>>>
>>>>> Ok. I see that there is another "example" configuration for AuriStream
>>>>> with just different syncPktTypes = 0x02BF and bandwidth = 3850.
>>>>>
>>>>> So it really is not simple as it can be seen.
>>>>
>>>> currently the stepping for mSBC and CVSD are hard-coded in esco_param_cvsd and esco_param_msbc arrays in hci_conn.c and then selected by the ->setting parameter.
>>>>
>>>> So either we provide an new socket option (for example BT_VOICE_EXT) or we extend BT_VOICE to allow providing the needed information. However this needs to be flexible array size since we should then be able to encode multiple stepping that are tried in order.
>>>>
>>>> My preference is that we extend BT_VOICE and not introduce a new socket option. So feel free to propose how we can load the full tables into the SCO socket. I mean we are not really far off actually. The only difference is that currently the tables are in the hci_conn.c file and selected by the provided voice->setting. However nothing really stops us from providing the full table via user space.
>>>
>>> Ok. I will look at it and I will try to propose how to extend current
>>> BT_VOICE ioctl API for supporting all those new parameters.
>>>
>>>>>>>> We have kept is really simple since there was only CVSD and mSBC as of now.
>>>>>>>
>>>>>>> Seems that custom codecs are already widely used, so it would be great
>>>>>>> it Linux kernel allows to use also other codecs in future without need
>>>>>>> to explicitly whitelist them.
>>>>>>
>>>>>> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.
>>>>>
>>>>> CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
>>>>> codecs but I have not seen it used. Has somebody tried to implement it?
>>>>> I think just replacing voice_settings should be enough as encoding /
>>>>> decoding should be done in bluetooth firmware / hardware.
>>>>>
>>>>> And then there is AuriStream which based on google results it supported
>>>>> by lot of headsets.
>>>>>
>>>>> So at least 3 different codecs are widely supported by headset.
>>>>
>>>> The ulaw and alaw air codecs are in theory possible, but nobody in the history of Bluetooth has used them. So just ignore that part of the specification. For air codecs you have either CVSD or transparent. And then with transparent you get mSBC and AuriStream.
>>>
>>> More interesting question would be if alaw codec can be used in
>>> transparent mode by transmitter and in "normal alaw" mode by receiver.
>>> So it is possible to "tell" bluetooth chip "hey, I have already prepared
>>> alaw or CVSD packets for you”?
>>
>> actually alaw is an over the air codec. Using it in transparent mode has no profile support. So while possible, it is not interoperable.
>
> I'm looking at Voice Setting parameters and it is possible to set Input
> Coding Format to alaw and also Air Coding Format to alaw. It is not
> Transparent Air mode, so above problem with profile interoperability
> does not have to be there. So in theory it should be possible to
> configure bluetooth chip to pass-thru alaw data without re-encoding
> them. So after new API for "unlocking" other non-whitelisted Voice
> Settings is there, this can start to be tested...
>
> Apparently there is no CVSD Input Coding Format in Voice Setting, so
> CVSD codec data cannot be pass-thru to bt chip via existing Setup
> Synchronous Connection. But there is Enhanced Setup Synchronous
> Connection command which does not use Voice Setting structure which
> seems to be more powerfull in codec handling.
ignore the alaw and ulaw codecs since they are not used. It is a relic from the early years of Bluetooth.
Regards
Marcel
Hi Pali,
>> I was playing with another suggestion for API:
>>
>> +#define BT_VOICE_SETUP 14
>> +struct bt_voice_pkt_type {
>> + __u8 capability; /* 0x01 - SCO; 0x02 - eSCO */
>> + __u8 retrans_effort;
>> + __u16 pkt_type;
>> + __u16 max_latency;
>> +};
>> +struct bt_voice_setup {
>> + __u16 voice_setting;
>> + __u16 pkt_types_count;
>> + __u32 tx_bandwidth;
>> + __u32 rx_bandwidth;
>> + struct bt_voice_pkt_type pkt_types[];
>> +};
>>
>> So voice_setttings, pkt_types_count and badwidth would not be repeated
>> as it is same for every pkt_type/retrans_effors/max_latency.
>>
>> But above uses C99 flexible arrays, so I do not know if API kernel <-->
>> userspace API is allowed to use C99 flexible arrays.
>>
>> But getsockopt/setsockopt functions are possible to write with above
>> API.
>
> I played more with C99 flexible arrays and seems that gcc supports it
> without any problems. I'm sending another attempt of API implementation,
> now with more fields which are needed for Enhanced Setup Synchronous
> Connection command. This command is not supported by kernel yet, but
> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> Setup Synchronous Connection command would be needed to use hardware
> mSBC codec encoder/decoder.
>
> --
> Pali Rohár
> [email protected]
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index fabee6db0abb..29590c6749d5 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -116,12 +116,49 @@ struct bt_voice {
> __u16 setting;
> };
>
> -#define BT_VOICE_TRANSPARENT 0x0003
> -#define BT_VOICE_CVSD_16BIT 0x0060
> -
> #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;
> +};
> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> +struct bt_voice_setup {
> + __u16 voice_setting;
> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> + __u8 pkt_types_count;
> + __u32 tx_bandwidth;
> + __u32 rx_bandwidth;
> + __u32 input_bandwidth;
> + __u32 output_bandwidth;
> + __u8 tx_coding_format[5];
> + __u8 rx_coding_format[5];
> + __u8 input_coding_format[5];
> + __u8 output_coding_format[5];
> + __u16 tx_codec_frame_size;
> + __u16 rx_codec_frame_size;
> + __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;
> + __u8 input_data_path;
> + __u8 output_data_path;
> + __u8 input_unit_size;
> + __u8 output_unit_size;
> + struct bt_voice_pkt_type pkt_types[];
> +};
> +
lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
Regards
Marcel
On Sunday 24 November 2019 12:04:39 Marcel Holtmann wrote:
> Hi Pali,
>
> > I played more with C99 flexible arrays and seems that gcc supports it
> > without any problems. I'm sending another attempt of API implementation,
> > now with more fields which are needed for Enhanced Setup Synchronous
> > Connection command. This command is not supported by kernel yet, but
> > should be easy to add it. So my ioctl API is prepared for it. Enhanced
> > Setup Synchronous Connection command would be needed to use hardware
> > mSBC codec encoder/decoder.
> >
> > --
> > Pali Rohár
> > [email protected]
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index fabee6db0abb..29590c6749d5 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -116,12 +116,49 @@ struct bt_voice {
> > __u16 setting;
> > };
> >
> > -#define BT_VOICE_TRANSPARENT 0x0003
> > -#define BT_VOICE_CVSD_16BIT 0x0060
> > -
> > #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;
> > +};
> > +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> > +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> > +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> > +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> > +struct bt_voice_setup {
> > + __u16 voice_setting;
> > + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> > + __u8 pkt_types_count;
> > + __u32 tx_bandwidth;
> > + __u32 rx_bandwidth;
> > + __u32 input_bandwidth;
> > + __u32 output_bandwidth;
> > + __u8 tx_coding_format[5];
> > + __u8 rx_coding_format[5];
> > + __u8 input_coding_format[5];
> > + __u8 output_coding_format[5];
> > + __u16 tx_codec_frame_size;
> > + __u16 rx_codec_frame_size;
> > + __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;
> > + __u8 input_data_path;
> > + __u8 output_data_path;
> > + __u8 input_unit_size;
> > + __u8 output_unit_size;
> > + struct bt_voice_pkt_type pkt_types[];
> > +};
> > +
>
> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
You are right that air codecs are defined by profile and local codecs by
platform / bluetooth adapter. But ...
> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
Above structure specify exactly one codec setup and then multiple packet
types. See that flexible array is only for packet types, not for whole
codec structure.
And all above parameters are required for Enhanced Setup Synchronous
Connection command. So kernel needs to know what should put into
Enhanced Setup Synchronous Connection command when creating a new SCO
connection. So for supporting Enhanced Setup Synchronous Connection
command userspace needs to pass all above parameters to kernel.
And usage of Enhanced Setup Synchronous Connection is required when we
want to use in-hardware encoding/decoding of mSBC codec. E.g. new
Thinkpads already have bluetooth adapter which supports encoding and
decoding of mSBC codec in hardware.
So above structure as I define is really needed. Do you see it now?
--
Pali Rohár
[email protected]
Hi Pali,
>>> I played more with C99 flexible arrays and seems that gcc supports it
>>> without any problems. I'm sending another attempt of API implementation,
>>> now with more fields which are needed for Enhanced Setup Synchronous
>>> Connection command. This command is not supported by kernel yet, but
>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
>>> Setup Synchronous Connection command would be needed to use hardware
>>> mSBC codec encoder/decoder.
>>>
>>> --
>>> Pali Rohár
>>> [email protected]
>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>>> index fabee6db0abb..29590c6749d5 100644
>>> --- a/include/net/bluetooth/bluetooth.h
>>> +++ b/include/net/bluetooth/bluetooth.h
>>> @@ -116,12 +116,49 @@ struct bt_voice {
>>> __u16 setting;
>>> };
>>>
>>> -#define BT_VOICE_TRANSPARENT 0x0003
>>> -#define BT_VOICE_CVSD_16BIT 0x0060
>>> -
>>> #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;
>>> +};
>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
>>> +struct bt_voice_setup {
>>> + __u16 voice_setting;
>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
>>> + __u8 pkt_types_count;
>>> + __u32 tx_bandwidth;
>>> + __u32 rx_bandwidth;
>>> + __u32 input_bandwidth;
>>> + __u32 output_bandwidth;
>>> + __u8 tx_coding_format[5];
>>> + __u8 rx_coding_format[5];
>>> + __u8 input_coding_format[5];
>>> + __u8 output_coding_format[5];
>>> + __u16 tx_codec_frame_size;
>>> + __u16 rx_codec_frame_size;
>>> + __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;
>>> + __u8 input_data_path;
>>> + __u8 output_data_path;
>>> + __u8 input_unit_size;
>>> + __u8 output_unit_size;
>>> + struct bt_voice_pkt_type pkt_types[];
>>> +};
>>> +
>>
>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
>
> You are right that air codecs are defined by profile and local codecs by
> platform / bluetooth adapter. But ...
>
>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
>
> Above structure specify exactly one codec setup and then multiple packet
> types. See that flexible array is only for packet types, not for whole
> codec structure.
>
> And all above parameters are required for Enhanced Setup Synchronous
> Connection command. So kernel needs to know what should put into
> Enhanced Setup Synchronous Connection command when creating a new SCO
> connection. So for supporting Enhanced Setup Synchronous Connection
> command userspace needs to pass all above parameters to kernel.
>
> And usage of Enhanced Setup Synchronous Connection is required when we
> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> Thinkpads already have bluetooth adapter which supports encoding and
> decoding of mSBC codec in hardware.
>
> So above structure as I define is really needed. Do you see it now?
the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
Regards
Marcel
On Tuesday 26 November 2019 08:24:04 Marcel Holtmann wrote:
> Hi Pali,
>
> >>> I played more with C99 flexible arrays and seems that gcc supports it
> >>> without any problems. I'm sending another attempt of API implementation,
> >>> now with more fields which are needed for Enhanced Setup Synchronous
> >>> Connection command. This command is not supported by kernel yet, but
> >>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> >>> Setup Synchronous Connection command would be needed to use hardware
> >>> mSBC codec encoder/decoder.
> >>>
> >>> --
> >>> Pali Rohár
> >>> [email protected]
> >>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> >>> index fabee6db0abb..29590c6749d5 100644
> >>> --- a/include/net/bluetooth/bluetooth.h
> >>> +++ b/include/net/bluetooth/bluetooth.h
> >>> @@ -116,12 +116,49 @@ struct bt_voice {
> >>> __u16 setting;
> >>> };
> >>>
> >>> -#define BT_VOICE_TRANSPARENT 0x0003
> >>> -#define BT_VOICE_CVSD_16BIT 0x0060
> >>> -
> >>> #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;
> >>> +};
> >>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> >>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> >>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> >>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> >>> +struct bt_voice_setup {
> >>> + __u16 voice_setting;
> >>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> >>> + __u8 pkt_types_count;
> >>> + __u32 tx_bandwidth;
> >>> + __u32 rx_bandwidth;
> >>> + __u32 input_bandwidth;
> >>> + __u32 output_bandwidth;
> >>> + __u8 tx_coding_format[5];
> >>> + __u8 rx_coding_format[5];
> >>> + __u8 input_coding_format[5];
> >>> + __u8 output_coding_format[5];
> >>> + __u16 tx_codec_frame_size;
> >>> + __u16 rx_codec_frame_size;
> >>> + __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;
> >>> + __u8 input_data_path;
> >>> + __u8 output_data_path;
> >>> + __u8 input_unit_size;
> >>> + __u8 output_unit_size;
> >>> + struct bt_voice_pkt_type pkt_types[];
> >>> +};
> >>> +
> >>
> >> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> >
> > You are right that air codecs are defined by profile and local codecs by
> > platform / bluetooth adapter. But ...
> >
> >> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> >
> > Above structure specify exactly one codec setup and then multiple packet
> > types. See that flexible array is only for packet types, not for whole
> > codec structure.
> >
> > And all above parameters are required for Enhanced Setup Synchronous
> > Connection command. So kernel needs to know what should put into
> > Enhanced Setup Synchronous Connection command when creating a new SCO
> > connection. So for supporting Enhanced Setup Synchronous Connection
> > command userspace needs to pass all above parameters to kernel.
> >
> > And usage of Enhanced Setup Synchronous Connection is required when we
> > want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> > Thinkpads already have bluetooth adapter which supports encoding and
> > decoding of mSBC codec in hardware.
> >
> > So above structure as I define is really needed. Do you see it now?
>
> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
Userspace needs to know if kernel expects sound data (via write()) in
mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
(via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
userspace is not possible to send any data to remote headset correctly.
--
Pali Rohár
[email protected]
Hi Pali,
>>>>> I played more with C99 flexible arrays and seems that gcc supports it
>>>>> without any problems. I'm sending another attempt of API implementation,
>>>>> now with more fields which are needed for Enhanced Setup Synchronous
>>>>> Connection command. This command is not supported by kernel yet, but
>>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
>>>>> Setup Synchronous Connection command would be needed to use hardware
>>>>> mSBC codec encoder/decoder.
>>>>>
>>>>> --
>>>>> Pali Rohár
>>>>> [email protected]
>>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>>>>> index fabee6db0abb..29590c6749d5 100644
>>>>> --- a/include/net/bluetooth/bluetooth.h
>>>>> +++ b/include/net/bluetooth/bluetooth.h
>>>>> @@ -116,12 +116,49 @@ struct bt_voice {
>>>>> __u16 setting;
>>>>> };
>>>>>
>>>>> -#define BT_VOICE_TRANSPARENT 0x0003
>>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
>>>>> -
>>>>> #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;
>>>>> +};
>>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
>>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
>>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
>>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
>>>>> +struct bt_voice_setup {
>>>>> + __u16 voice_setting;
>>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
>>>>> + __u8 pkt_types_count;
>>>>> + __u32 tx_bandwidth;
>>>>> + __u32 rx_bandwidth;
>>>>> + __u32 input_bandwidth;
>>>>> + __u32 output_bandwidth;
>>>>> + __u8 tx_coding_format[5];
>>>>> + __u8 rx_coding_format[5];
>>>>> + __u8 input_coding_format[5];
>>>>> + __u8 output_coding_format[5];
>>>>> + __u16 tx_codec_frame_size;
>>>>> + __u16 rx_codec_frame_size;
>>>>> + __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;
>>>>> + __u8 input_data_path;
>>>>> + __u8 output_data_path;
>>>>> + __u8 input_unit_size;
>>>>> + __u8 output_unit_size;
>>>>> + struct bt_voice_pkt_type pkt_types[];
>>>>> +};
>>>>> +
>>>>
>>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
>>>
>>> You are right that air codecs are defined by profile and local codecs by
>>> platform / bluetooth adapter. But ...
>>>
>>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
>>>
>>> Above structure specify exactly one codec setup and then multiple packet
>>> types. See that flexible array is only for packet types, not for whole
>>> codec structure.
>>>
>>> And all above parameters are required for Enhanced Setup Synchronous
>>> Connection command. So kernel needs to know what should put into
>>> Enhanced Setup Synchronous Connection command when creating a new SCO
>>> connection. So for supporting Enhanced Setup Synchronous Connection
>>> command userspace needs to pass all above parameters to kernel.
>>>
>>> And usage of Enhanced Setup Synchronous Connection is required when we
>>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
>>> Thinkpads already have bluetooth adapter which supports encoding and
>>> decoding of mSBC codec in hardware.
>>>
>>> So above structure as I define is really needed. Do you see it now?
>>
>> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
>
> Userspace needs to know if kernel expects sound data (via write()) in
> mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> userspace is not possible to send any data to remote headset correctly.
true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
Regards
Marcel
On Tuesday 26 November 2019 08:58:44 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>> I played more with C99 flexible arrays and seems that gcc supports it
> >>>>> without any problems. I'm sending another attempt of API implementation,
> >>>>> now with more fields which are needed for Enhanced Setup Synchronous
> >>>>> Connection command. This command is not supported by kernel yet, but
> >>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> >>>>> Setup Synchronous Connection command would be needed to use hardware
> >>>>> mSBC codec encoder/decoder.
> >>>>>
> >>>>> --
> >>>>> Pali Rohár
> >>>>> [email protected]
> >>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> >>>>> index fabee6db0abb..29590c6749d5 100644
> >>>>> --- a/include/net/bluetooth/bluetooth.h
> >>>>> +++ b/include/net/bluetooth/bluetooth.h
> >>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> >>>>> __u16 setting;
> >>>>> };
> >>>>>
> >>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> >>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> >>>>> -
> >>>>> #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;
> >>>>> +};
> >>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> >>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> >>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> >>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> >>>>> +struct bt_voice_setup {
> >>>>> + __u16 voice_setting;
> >>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> >>>>> + __u8 pkt_types_count;
> >>>>> + __u32 tx_bandwidth;
> >>>>> + __u32 rx_bandwidth;
> >>>>> + __u32 input_bandwidth;
> >>>>> + __u32 output_bandwidth;
> >>>>> + __u8 tx_coding_format[5];
> >>>>> + __u8 rx_coding_format[5];
> >>>>> + __u8 input_coding_format[5];
> >>>>> + __u8 output_coding_format[5];
> >>>>> + __u16 tx_codec_frame_size;
> >>>>> + __u16 rx_codec_frame_size;
> >>>>> + __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;
> >>>>> + __u8 input_data_path;
> >>>>> + __u8 output_data_path;
> >>>>> + __u8 input_unit_size;
> >>>>> + __u8 output_unit_size;
> >>>>> + struct bt_voice_pkt_type pkt_types[];
> >>>>> +};
> >>>>> +
> >>>>
> >>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> >>>
> >>> You are right that air codecs are defined by profile and local codecs by
> >>> platform / bluetooth adapter. But ...
> >>>
> >>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> >>>
> >>> Above structure specify exactly one codec setup and then multiple packet
> >>> types. See that flexible array is only for packet types, not for whole
> >>> codec structure.
> >>>
> >>> And all above parameters are required for Enhanced Setup Synchronous
> >>> Connection command. So kernel needs to know what should put into
> >>> Enhanced Setup Synchronous Connection command when creating a new SCO
> >>> connection. So for supporting Enhanced Setup Synchronous Connection
> >>> command userspace needs to pass all above parameters to kernel.
> >>>
> >>> And usage of Enhanced Setup Synchronous Connection is required when we
> >>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> >>> Thinkpads already have bluetooth adapter which supports encoding and
> >>> decoding of mSBC codec in hardware.
> >>>
> >>> So above structure as I define is really needed. Do you see it now?
> >>
> >> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> >
> > Userspace needs to know if kernel expects sound data (via write()) in
> > mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> > (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> > userspace is not possible to send any data to remote headset correctly.
>
> true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
Ok, so how would userspace then can set those other informations?
--
Pali Rohár
[email protected]
Hi Pali,
On Tue, Nov 26, 2019 at 10:00 AM Pali Rohár <[email protected]> wrote:
>
> On Tuesday 26 November 2019 08:58:44 Marcel Holtmann wrote:
> > Hi Pali,
> >
> > >>>>> I played more with C99 flexible arrays and seems that gcc supports it
> > >>>>> without any problems. I'm sending another attempt of API implementation,
> > >>>>> now with more fields which are needed for Enhanced Setup Synchronous
> > >>>>> Connection command. This command is not supported by kernel yet, but
> > >>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> > >>>>> Setup Synchronous Connection command would be needed to use hardware
> > >>>>> mSBC codec encoder/decoder.
> > >>>>>
> > >>>>> --
> > >>>>> Pali Rohár
> > >>>>> [email protected]
> > >>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > >>>>> index fabee6db0abb..29590c6749d5 100644
> > >>>>> --- a/include/net/bluetooth/bluetooth.h
> > >>>>> +++ b/include/net/bluetooth/bluetooth.h
> > >>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> > >>>>> __u16 setting;
> > >>>>> };
> > >>>>>
> > >>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> > >>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> > >>>>> -
> > >>>>> #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;
> > >>>>> +};
> > >>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> > >>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> > >>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> > >>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> > >>>>> +struct bt_voice_setup {
> > >>>>> + __u16 voice_setting;
> > >>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> > >>>>> + __u8 pkt_types_count;
> > >>>>> + __u32 tx_bandwidth;
> > >>>>> + __u32 rx_bandwidth;
> > >>>>> + __u32 input_bandwidth;
> > >>>>> + __u32 output_bandwidth;
> > >>>>> + __u8 tx_coding_format[5];
> > >>>>> + __u8 rx_coding_format[5];
> > >>>>> + __u8 input_coding_format[5];
> > >>>>> + __u8 output_coding_format[5];
> > >>>>> + __u16 tx_codec_frame_size;
> > >>>>> + __u16 rx_codec_frame_size;
> > >>>>> + __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;
> > >>>>> + __u8 input_data_path;
> > >>>>> + __u8 output_data_path;
> > >>>>> + __u8 input_unit_size;
> > >>>>> + __u8 output_unit_size;
> > >>>>> + struct bt_voice_pkt_type pkt_types[];
> > >>>>> +};
> > >>>>> +
> > >>>>
> > >>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> > >>>
> > >>> You are right that air codecs are defined by profile and local codecs by
> > >>> platform / bluetooth adapter. But ...
> > >>>
> > >>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> > >>>
> > >>> Above structure specify exactly one codec setup and then multiple packet
> > >>> types. See that flexible array is only for packet types, not for whole
> > >>> codec structure.
> > >>>
> > >>> And all above parameters are required for Enhanced Setup Synchronous
> > >>> Connection command. So kernel needs to know what should put into
> > >>> Enhanced Setup Synchronous Connection command when creating a new SCO
> > >>> connection. So for supporting Enhanced Setup Synchronous Connection
> > >>> command userspace needs to pass all above parameters to kernel.
> > >>>
> > >>> And usage of Enhanced Setup Synchronous Connection is required when we
> > >>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> > >>> Thinkpads already have bluetooth adapter which supports encoding and
> > >>> decoding of mSBC codec in hardware.
> > >>>
> > >>> So above structure as I define is really needed. Do you see it now?
> > >>
> > >> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> > >
> > > Userspace needs to know if kernel expects sound data (via write()) in
> > > mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> > > (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> > > userspace is not possible to send any data to remote headset correctly.
> >
> > true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
>
> Ok, so how would userspace then can set those other informations?
So to jump in the middle of the discussion but what other formats does
the userspace would like to use? Afaik we only have PCM_s16le and
transparent encoded data support so far.
--
Luiz Augusto von Dentz
On Tuesday 26 November 2019 11:41:50 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Tue, Nov 26, 2019 at 10:00 AM Pali Rohár <[email protected]> wrote:
> >
> > On Tuesday 26 November 2019 08:58:44 Marcel Holtmann wrote:
> > > Hi Pali,
> > >
> > > >>>>> I played more with C99 flexible arrays and seems that gcc supports it
> > > >>>>> without any problems. I'm sending another attempt of API implementation,
> > > >>>>> now with more fields which are needed for Enhanced Setup Synchronous
> > > >>>>> Connection command. This command is not supported by kernel yet, but
> > > >>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> > > >>>>> Setup Synchronous Connection command would be needed to use hardware
> > > >>>>> mSBC codec encoder/decoder.
> > > >>>>>
> > > >>>>> --
> > > >>>>> Pali Rohár
> > > >>>>> [email protected]
> > > >>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > > >>>>> index fabee6db0abb..29590c6749d5 100644
> > > >>>>> --- a/include/net/bluetooth/bluetooth.h
> > > >>>>> +++ b/include/net/bluetooth/bluetooth.h
> > > >>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> > > >>>>> __u16 setting;
> > > >>>>> };
> > > >>>>>
> > > >>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> > > >>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> > > >>>>> -
> > > >>>>> #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;
> > > >>>>> +};
> > > >>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> > > >>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> > > >>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> > > >>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> > > >>>>> +struct bt_voice_setup {
> > > >>>>> + __u16 voice_setting;
> > > >>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> > > >>>>> + __u8 pkt_types_count;
> > > >>>>> + __u32 tx_bandwidth;
> > > >>>>> + __u32 rx_bandwidth;
> > > >>>>> + __u32 input_bandwidth;
> > > >>>>> + __u32 output_bandwidth;
> > > >>>>> + __u8 tx_coding_format[5];
> > > >>>>> + __u8 rx_coding_format[5];
> > > >>>>> + __u8 input_coding_format[5];
> > > >>>>> + __u8 output_coding_format[5];
> > > >>>>> + __u16 tx_codec_frame_size;
> > > >>>>> + __u16 rx_codec_frame_size;
> > > >>>>> + __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;
> > > >>>>> + __u8 input_data_path;
> > > >>>>> + __u8 output_data_path;
> > > >>>>> + __u8 input_unit_size;
> > > >>>>> + __u8 output_unit_size;
> > > >>>>> + struct bt_voice_pkt_type pkt_types[];
> > > >>>>> +};
> > > >>>>> +
> > > >>>>
> > > >>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> > > >>>
> > > >>> You are right that air codecs are defined by profile and local codecs by
> > > >>> platform / bluetooth adapter. But ...
> > > >>>
> > > >>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> > > >>>
> > > >>> Above structure specify exactly one codec setup and then multiple packet
> > > >>> types. See that flexible array is only for packet types, not for whole
> > > >>> codec structure.
> > > >>>
> > > >>> And all above parameters are required for Enhanced Setup Synchronous
> > > >>> Connection command. So kernel needs to know what should put into
> > > >>> Enhanced Setup Synchronous Connection command when creating a new SCO
> > > >>> connection. So for supporting Enhanced Setup Synchronous Connection
> > > >>> command userspace needs to pass all above parameters to kernel.
> > > >>>
> > > >>> And usage of Enhanced Setup Synchronous Connection is required when we
> > > >>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> > > >>> Thinkpads already have bluetooth adapter which supports encoding and
> > > >>> decoding of mSBC codec in hardware.
> > > >>>
> > > >>> So above structure as I define is really needed. Do you see it now?
> > > >>
> > > >> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> > > >
> > > > Userspace needs to know if kernel expects sound data (via write()) in
> > > > mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> > > > (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> > > > userspace is not possible to send any data to remote headset correctly.
> > >
> > > true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
> >
> > Ok, so how would userspace then can set those other informations?
>
> So to jump in the middle of the discussion but what other formats does
> the userspace would like to use? Afaik we only have PCM_s16le and
> transparent encoded data support so far.
Hi Luiz! As I wrote above, e.g. bluetooth adapters in new Thinkpads
supports in-hardware mSBC encoding/decoding. So you need to say to
adapter if you want mSBC or PCM_s16le. Not "transparent". But it needs
to use "Enhanced Setup Synchronous Connection" call not just basic
"Setup Synchronous Connection". Structure which I defined above is just
copy of parameters which needs to be passed to "Enhanced Setup
Synchronous Connection" call.
--
Pali Rohár
[email protected]
On Tuesday 26 November 2019 10:58:38 Pali Rohár wrote:
> On Tuesday 26 November 2019 11:41:50 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Tue, Nov 26, 2019 at 10:00 AM Pali Rohár <[email protected]> wrote:
> > >
> > > On Tuesday 26 November 2019 08:58:44 Marcel Holtmann wrote:
> > > > Hi Pali,
> > > >
> > > > >>>>> I played more with C99 flexible arrays and seems that gcc supports it
> > > > >>>>> without any problems. I'm sending another attempt of API implementation,
> > > > >>>>> now with more fields which are needed for Enhanced Setup Synchronous
> > > > >>>>> Connection command. This command is not supported by kernel yet, but
> > > > >>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> > > > >>>>> Setup Synchronous Connection command would be needed to use hardware
> > > > >>>>> mSBC codec encoder/decoder.
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Pali Rohár
> > > > >>>>> [email protected]
> > > > >>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > > > >>>>> index fabee6db0abb..29590c6749d5 100644
> > > > >>>>> --- a/include/net/bluetooth/bluetooth.h
> > > > >>>>> +++ b/include/net/bluetooth/bluetooth.h
> > > > >>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> > > > >>>>> __u16 setting;
> > > > >>>>> };
> > > > >>>>>
> > > > >>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> > > > >>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> > > > >>>>> -
> > > > >>>>> #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;
> > > > >>>>> +};
> > > > >>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> > > > >>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> > > > >>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> > > > >>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> > > > >>>>> +struct bt_voice_setup {
> > > > >>>>> + __u16 voice_setting;
> > > > >>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> > > > >>>>> + __u8 pkt_types_count;
> > > > >>>>> + __u32 tx_bandwidth;
> > > > >>>>> + __u32 rx_bandwidth;
> > > > >>>>> + __u32 input_bandwidth;
> > > > >>>>> + __u32 output_bandwidth;
> > > > >>>>> + __u8 tx_coding_format[5];
> > > > >>>>> + __u8 rx_coding_format[5];
> > > > >>>>> + __u8 input_coding_format[5];
> > > > >>>>> + __u8 output_coding_format[5];
> > > > >>>>> + __u16 tx_codec_frame_size;
> > > > >>>>> + __u16 rx_codec_frame_size;
> > > > >>>>> + __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;
> > > > >>>>> + __u8 input_data_path;
> > > > >>>>> + __u8 output_data_path;
> > > > >>>>> + __u8 input_unit_size;
> > > > >>>>> + __u8 output_unit_size;
> > > > >>>>> + struct bt_voice_pkt_type pkt_types[];
> > > > >>>>> +};
> > > > >>>>> +
> > > > >>>>
> > > > >>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> > > > >>>
> > > > >>> You are right that air codecs are defined by profile and local codecs by
> > > > >>> platform / bluetooth adapter. But ...
> > > > >>>
> > > > >>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> > > > >>>
> > > > >>> Above structure specify exactly one codec setup and then multiple packet
> > > > >>> types. See that flexible array is only for packet types, not for whole
> > > > >>> codec structure.
> > > > >>>
> > > > >>> And all above parameters are required for Enhanced Setup Synchronous
> > > > >>> Connection command. So kernel needs to know what should put into
> > > > >>> Enhanced Setup Synchronous Connection command when creating a new SCO
> > > > >>> connection. So for supporting Enhanced Setup Synchronous Connection
> > > > >>> command userspace needs to pass all above parameters to kernel.
> > > > >>>
> > > > >>> And usage of Enhanced Setup Synchronous Connection is required when we
> > > > >>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> > > > >>> Thinkpads already have bluetooth adapter which supports encoding and
> > > > >>> decoding of mSBC codec in hardware.
> > > > >>>
> > > > >>> So above structure as I define is really needed. Do you see it now?
> > > > >>
> > > > >> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> > > > >
> > > > > Userspace needs to know if kernel expects sound data (via write()) in
> > > > > mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> > > > > (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> > > > > userspace is not possible to send any data to remote headset correctly.
> > > >
> > > > true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
> > >
> > > Ok, so how would userspace then can set those other informations?
> >
> > So to jump in the middle of the discussion but what other formats does
> > the userspace would like to use? Afaik we only have PCM_s16le and
> > transparent encoded data support so far.
>
> Hi Luiz! As I wrote above, e.g. bluetooth adapters in new Thinkpads
> supports in-hardware mSBC encoding/decoding. So you need to say to
> adapter if you want mSBC or PCM_s16le. Not "transparent". But it needs
> to use "Enhanced Setup Synchronous Connection" call not just basic
> "Setup Synchronous Connection". Structure which I defined above is just
> copy of parameters which needs to be passed to "Enhanced Setup
> Synchronous Connection" call.
>
Hello, can we move forward in this problem? If above my proposed API for
setting codecs settings is not suitable, could you please propose
different which would provide needed functionality?
Because kernel is currently blocking usage of any other codec and
therefore without fixing this issue it is not possible to use any other
codec.
Also kernel is blocking usage of hardware mSBC encoder and decoder which
is part of bluetooth adapters (e.g. in new Thinkpads) so it is still
needed to do whole encoding / decoding in software...
--
Pali Rohár
[email protected]
Just a reminder for this email...
On Thursday 05 December 2019 10:28:47 Pali Rohár wrote:
> Hello, can we move forward in this problem? If above my proposed API for
> setting codecs settings is not suitable, could you please propose
> different which would provide needed functionality?
>
> Because kernel is currently blocking usage of any other codec and
> therefore without fixing this issue it is not possible to use any other
> codec.
>
> Also kernel is blocking usage of hardware mSBC encoder and decoder which
> is part of bluetooth adapters (e.g. in new Thinkpads) so it is still
> needed to do whole encoding / decoding in software...
--
Pali Rohár
[email protected]
Hi Pali,
>>>>>>>>>> I played more with C99 flexible arrays and seems that gcc supports it
>>>>>>>>>> without any problems. I'm sending another attempt of API implementation,
>>>>>>>>>> now with more fields which are needed for Enhanced Setup Synchronous
>>>>>>>>>> Connection command. This command is not supported by kernel yet, but
>>>>>>>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
>>>>>>>>>> Setup Synchronous Connection command would be needed to use hardware
>>>>>>>>>> mSBC codec encoder/decoder.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Pali Rohár
>>>>>>>>>> [email protected]
>>>>>>>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>>>>>>>>>> index fabee6db0abb..29590c6749d5 100644
>>>>>>>>>> --- a/include/net/bluetooth/bluetooth.h
>>>>>>>>>> +++ b/include/net/bluetooth/bluetooth.h
>>>>>>>>>> @@ -116,12 +116,49 @@ struct bt_voice {
>>>>>>>>>> __u16 setting;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> -#define BT_VOICE_TRANSPARENT 0x0003
>>>>>>>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
>>>>>>>>>> -
>>>>>>>>>> #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;
>>>>>>>>>> +};
>>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
>>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
>>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
>>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
>>>>>>>>>> +struct bt_voice_setup {
>>>>>>>>>> + __u16 voice_setting;
>>>>>>>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
>>>>>>>>>> + __u8 pkt_types_count;
>>>>>>>>>> + __u32 tx_bandwidth;
>>>>>>>>>> + __u32 rx_bandwidth;
>>>>>>>>>> + __u32 input_bandwidth;
>>>>>>>>>> + __u32 output_bandwidth;
>>>>>>>>>> + __u8 tx_coding_format[5];
>>>>>>>>>> + __u8 rx_coding_format[5];
>>>>>>>>>> + __u8 input_coding_format[5];
>>>>>>>>>> + __u8 output_coding_format[5];
>>>>>>>>>> + __u16 tx_codec_frame_size;
>>>>>>>>>> + __u16 rx_codec_frame_size;
>>>>>>>>>> + __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;
>>>>>>>>>> + __u8 input_data_path;
>>>>>>>>>> + __u8 output_data_path;
>>>>>>>>>> + __u8 input_unit_size;
>>>>>>>>>> + __u8 output_unit_size;
>>>>>>>>>> + struct bt_voice_pkt_type pkt_types[];
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>
>>>>>>>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
>>>>>>>>
>>>>>>>> You are right that air codecs are defined by profile and local codecs by
>>>>>>>> platform / bluetooth adapter. But ...
>>>>>>>>
>>>>>>>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
>>>>>>>>
>>>>>>>> Above structure specify exactly one codec setup and then multiple packet
>>>>>>>> types. See that flexible array is only for packet types, not for whole
>>>>>>>> codec structure.
>>>>>>>>
>>>>>>>> And all above parameters are required for Enhanced Setup Synchronous
>>>>>>>> Connection command. So kernel needs to know what should put into
>>>>>>>> Enhanced Setup Synchronous Connection command when creating a new SCO
>>>>>>>> connection. So for supporting Enhanced Setup Synchronous Connection
>>>>>>>> command userspace needs to pass all above parameters to kernel.
>>>>>>>>
>>>>>>>> And usage of Enhanced Setup Synchronous Connection is required when we
>>>>>>>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
>>>>>>>> Thinkpads already have bluetooth adapter which supports encoding and
>>>>>>>> decoding of mSBC codec in hardware.
>>>>>>>>
>>>>>>>> So above structure as I define is really needed. Do you see it now?
>>>>>>>
>>>>>>> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
>>>>>>
>>>>>> Userspace needs to know if kernel expects sound data (via write()) in
>>>>>> mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
>>>>>> (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
>>>>>> userspace is not possible to send any data to remote headset correctly.
>>>>>
>>>>> true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
>>>>
>>>> Ok, so how would userspace then can set those other informations?
>>>
>>> So to jump in the middle of the discussion but what other formats does
>>> the userspace would like to use? Afaik we only have PCM_s16le and
>>> transparent encoded data support so far.
>>
>> Hi Luiz! As I wrote above, e.g. bluetooth adapters in new Thinkpads
>> supports in-hardware mSBC encoding/decoding. So you need to say to
>> adapter if you want mSBC or PCM_s16le. Not "transparent". But it needs
>> to use "Enhanced Setup Synchronous Connection" call not just basic
>> "Setup Synchronous Connection". Structure which I defined above is just
>> copy of parameters which needs to be passed to "Enhanced Setup
>> Synchronous Connection" call.
>>
>
> Hello, can we move forward in this problem? If above my proposed API for
> setting codecs settings is not suitable, could you please propose
> different which would provide needed functionality?
>
> Because kernel is currently blocking usage of any other codec and
> therefore without fixing this issue it is not possible to use any other
> codec.
>
> Also kernel is blocking usage of hardware mSBC encoder and decoder which
> is part of bluetooth adapters (e.g. in new Thinkpads) so it is still
> needed to do whole encoding / decoding in software...
the interface to the kernel needs to minimal. Tell it what you want and it tells you back what you got. Exposing a HCI command structure via ioctl is not the solution.
Regards
Marcel
On Saturday 04 January 2020 11:04:14 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>>> I played more with C99 flexible arrays and seems that gcc supports it
> >>>>>>>>>> without any problems. I'm sending another attempt of API implementation,
> >>>>>>>>>> now with more fields which are needed for Enhanced Setup Synchronous
> >>>>>>>>>> Connection command. This command is not supported by kernel yet, but
> >>>>>>>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> >>>>>>>>>> Setup Synchronous Connection command would be needed to use hardware
> >>>>>>>>>> mSBC codec encoder/decoder.
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Pali Rohár
> >>>>>>>>>> [email protected]
> >>>>>>>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> >>>>>>>>>> index fabee6db0abb..29590c6749d5 100644
> >>>>>>>>>> --- a/include/net/bluetooth/bluetooth.h
> >>>>>>>>>> +++ b/include/net/bluetooth/bluetooth.h
> >>>>>>>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> >>>>>>>>>> __u16 setting;
> >>>>>>>>>> };
> >>>>>>>>>>
> >>>>>>>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> >>>>>>>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> >>>>>>>>>> -
> >>>>>>>>>> #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;
> >>>>>>>>>> +};
> >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> >>>>>>>>>> +struct bt_voice_setup {
> >>>>>>>>>> + __u16 voice_setting;
> >>>>>>>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> >>>>>>>>>> + __u8 pkt_types_count;
> >>>>>>>>>> + __u32 tx_bandwidth;
> >>>>>>>>>> + __u32 rx_bandwidth;
> >>>>>>>>>> + __u32 input_bandwidth;
> >>>>>>>>>> + __u32 output_bandwidth;
> >>>>>>>>>> + __u8 tx_coding_format[5];
> >>>>>>>>>> + __u8 rx_coding_format[5];
> >>>>>>>>>> + __u8 input_coding_format[5];
> >>>>>>>>>> + __u8 output_coding_format[5];
> >>>>>>>>>> + __u16 tx_codec_frame_size;
> >>>>>>>>>> + __u16 rx_codec_frame_size;
> >>>>>>>>>> + __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;
> >>>>>>>>>> + __u8 input_data_path;
> >>>>>>>>>> + __u8 output_data_path;
> >>>>>>>>>> + __u8 input_unit_size;
> >>>>>>>>>> + __u8 output_unit_size;
> >>>>>>>>>> + struct bt_voice_pkt_type pkt_types[];
> >>>>>>>>>> +};
> >>>>>>>>>> +
> >>>>>>>>>
> >>>>>>>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> >>>>>>>>
> >>>>>>>> You are right that air codecs are defined by profile and local codecs by
> >>>>>>>> platform / bluetooth adapter. But ...
> >>>>>>>>
> >>>>>>>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> >>>>>>>>
> >>>>>>>> Above structure specify exactly one codec setup and then multiple packet
> >>>>>>>> types. See that flexible array is only for packet types, not for whole
> >>>>>>>> codec structure.
> >>>>>>>>
> >>>>>>>> And all above parameters are required for Enhanced Setup Synchronous
> >>>>>>>> Connection command. So kernel needs to know what should put into
> >>>>>>>> Enhanced Setup Synchronous Connection command when creating a new SCO
> >>>>>>>> connection. So for supporting Enhanced Setup Synchronous Connection
> >>>>>>>> command userspace needs to pass all above parameters to kernel.
> >>>>>>>>
> >>>>>>>> And usage of Enhanced Setup Synchronous Connection is required when we
> >>>>>>>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> >>>>>>>> Thinkpads already have bluetooth adapter which supports encoding and
> >>>>>>>> decoding of mSBC codec in hardware.
> >>>>>>>>
> >>>>>>>> So above structure as I define is really needed. Do you see it now?
> >>>>>>>
> >>>>>>> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> >>>>>>
> >>>>>> Userspace needs to know if kernel expects sound data (via write()) in
> >>>>>> mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> >>>>>> (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> >>>>>> userspace is not possible to send any data to remote headset correctly.
> >>>>>
> >>>>> true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
> >>>>
> >>>> Ok, so how would userspace then can set those other informations?
> >>>
> >>> So to jump in the middle of the discussion but what other formats does
> >>> the userspace would like to use? Afaik we only have PCM_s16le and
> >>> transparent encoded data support so far.
> >>
> >> Hi Luiz! As I wrote above, e.g. bluetooth adapters in new Thinkpads
> >> supports in-hardware mSBC encoding/decoding. So you need to say to
> >> adapter if you want mSBC or PCM_s16le. Not "transparent". But it needs
> >> to use "Enhanced Setup Synchronous Connection" call not just basic
> >> "Setup Synchronous Connection". Structure which I defined above is just
> >> copy of parameters which needs to be passed to "Enhanced Setup
> >> Synchronous Connection" call.
> >>
> >
> > Hello, can we move forward in this problem? If above my proposed API for
> > setting codecs settings is not suitable, could you please propose
> > different which would provide needed functionality?
> >
> > Because kernel is currently blocking usage of any other codec and
> > therefore without fixing this issue it is not possible to use any other
> > codec.
> >
> > Also kernel is blocking usage of hardware mSBC encoder and decoder which
> > is part of bluetooth adapters (e.g. in new Thinkpads) so it is still
> > needed to do whole encoding / decoding in software...
>
> the interface to the kernel needs to minimal. Tell it what you want and it tells you back what you got. Exposing a HCI command structure via ioctl is not the solution.
Marcel, as I said in first email, to use one specific AuriStream codec,
kernel needs to set following SCO properties:
syncPktTypes = 0x003F
bandwidth = 4000
max_latency = 16
voice_settings = 0x63
retx_effort = 2
And to use hardware encoder (e.g. mSBC), kernel needs to userspace allow
to set all parameters for "Enhanced Setup Synchronous Connection" HCI
command.
Otherwise userspace cannot use hardware encoder/decoder.
I do no know how to create more minimal interface as one which I
proposed to allow usage of both AuriStream and also in-hardware
encoders/decoders.
If you do not like my proposed API for it, could you please show me
different solution for API which would allow userspace applications
(e.g. pulseaudio) to use AuriStream codec and also would be able to use
in-hardware encoder/decoders? So pulseaudio would not have to use own
software encoder/decoder when bluetooth adapter supports it in HW?
--
Pali Rohár
[email protected]
On Saturday 04 January 2020 11:37:02 Pali Rohár wrote:
> On Saturday 04 January 2020 11:04:14 Marcel Holtmann wrote:
> > Hi Pali,
> >
> > >>>>>>>>>> I played more with C99 flexible arrays and seems that gcc supports it
> > >>>>>>>>>> without any problems. I'm sending another attempt of API implementation,
> > >>>>>>>>>> now with more fields which are needed for Enhanced Setup Synchronous
> > >>>>>>>>>> Connection command. This command is not supported by kernel yet, but
> > >>>>>>>>>> should be easy to add it. So my ioctl API is prepared for it. Enhanced
> > >>>>>>>>>> Setup Synchronous Connection command would be needed to use hardware
> > >>>>>>>>>> mSBC codec encoder/decoder.
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Pali Rohár
> > >>>>>>>>>> [email protected]
> > >>>>>>>>>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > >>>>>>>>>> index fabee6db0abb..29590c6749d5 100644
> > >>>>>>>>>> --- a/include/net/bluetooth/bluetooth.h
> > >>>>>>>>>> +++ b/include/net/bluetooth/bluetooth.h
> > >>>>>>>>>> @@ -116,12 +116,49 @@ struct bt_voice {
> > >>>>>>>>>> __u16 setting;
> > >>>>>>>>>> };
> > >>>>>>>>>>
> > >>>>>>>>>> -#define BT_VOICE_TRANSPARENT 0x0003
> > >>>>>>>>>> -#define BT_VOICE_CVSD_16BIT 0x0060
> > >>>>>>>>>> -
> > >>>>>>>>>> #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;
> > >>>>>>>>>> +};
> > >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_CONFIG BIT(0) /* Additional configuration fields after voice_settings are set (including other features) */
> > >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ADD_SCO BIT(1) /* Can use Add Synchronous Connection */
> > >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_SETUP_SCO BIT(2) /* Can use Setup Synchronous Connection */
> > >>>>>>>>>> +#define BT_VOICE_SETUP_FEATURE_ENH_SETUP_SCO BIT(3) /* Can use Enhanced Setup Synchronous Connection */
> > >>>>>>>>>> +struct bt_voice_setup {
> > >>>>>>>>>> + __u16 voice_setting;
> > >>>>>>>>>> + __u8 features; /* bitmask of BT_VOICE_SETUP_FEATURE_* */
> > >>>>>>>>>> + __u8 pkt_types_count;
> > >>>>>>>>>> + __u32 tx_bandwidth;
> > >>>>>>>>>> + __u32 rx_bandwidth;
> > >>>>>>>>>> + __u32 input_bandwidth;
> > >>>>>>>>>> + __u32 output_bandwidth;
> > >>>>>>>>>> + __u8 tx_coding_format[5];
> > >>>>>>>>>> + __u8 rx_coding_format[5];
> > >>>>>>>>>> + __u8 input_coding_format[5];
> > >>>>>>>>>> + __u8 output_coding_format[5];
> > >>>>>>>>>> + __u16 tx_codec_frame_size;
> > >>>>>>>>>> + __u16 rx_codec_frame_size;
> > >>>>>>>>>> + __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;
> > >>>>>>>>>> + __u8 input_data_path;
> > >>>>>>>>>> + __u8 output_data_path;
> > >>>>>>>>>> + __u8 input_unit_size;
> > >>>>>>>>>> + __u8 output_unit_size;
> > >>>>>>>>>> + struct bt_voice_pkt_type pkt_types[];
> > >>>>>>>>>> +};
> > >>>>>>>>>> +
> > >>>>>>>>>
> > >>>>>>>>> lets not mush these together. One of these are air codecs and setup defined by a profile, the other are local codec path defined by the platform.
> > >>>>>>>>
> > >>>>>>>> You are right that air codecs are defined by profile and local codecs by
> > >>>>>>>> platform / bluetooth adapter. But ...
> > >>>>>>>>
> > >>>>>>>>> You will also not have multiple local codec path. That will be one and they will not be negotiated. The eSCO settings however will be negotiated.
> > >>>>>>>>
> > >>>>>>>> Above structure specify exactly one codec setup and then multiple packet
> > >>>>>>>> types. See that flexible array is only for packet types, not for whole
> > >>>>>>>> codec structure.
> > >>>>>>>>
> > >>>>>>>> And all above parameters are required for Enhanced Setup Synchronous
> > >>>>>>>> Connection command. So kernel needs to know what should put into
> > >>>>>>>> Enhanced Setup Synchronous Connection command when creating a new SCO
> > >>>>>>>> connection. So for supporting Enhanced Setup Synchronous Connection
> > >>>>>>>> command userspace needs to pass all above parameters to kernel.
> > >>>>>>>>
> > >>>>>>>> And usage of Enhanced Setup Synchronous Connection is required when we
> > >>>>>>>> want to use in-hardware encoding/decoding of mSBC codec. E.g. new
> > >>>>>>>> Thinkpads already have bluetooth adapter which supports encoding and
> > >>>>>>>> decoding of mSBC codec in hardware.
> > >>>>>>>>
> > >>>>>>>> So above structure as I define is really needed. Do you see it now?
> > >>>>>>>
> > >>>>>>> the information are needed, but not that struct. It makes no sense to hand this problem of configuring the PCM data path correctly to the profile code. So I am not going to do that. The profile itself has no interest in how the platform is built. What you are going to do is configure possible PCM data path options and then the kernel will use that information for Enhanced Sync Setup. However the profile should only provide the over-the-air settings since that is what is going to be negotiated during the profile setup.
> > >>>>>>
> > >>>>>> Userspace needs to know if kernel expects sound data (via write()) in
> > >>>>>> mSBC or in PCM_s16le. Also userspace needs to know if kernel provides
> > >>>>>> (via read()) sound data in mSBC, PCM_s16le or in other format. Otherwise
> > >>>>>> userspace is not possible to send any data to remote headset correctly.
> > >>>>>
> > >>>>> true, but the profile implementation doesn’t care. It is the audio component eg. PA that cares. Only because HCI has a single command for things, doesn’t mean we are stuffing all of the information via a single ioctl and then let userspace deal with the mess. That is not how we designed things.
> > >>>>
> > >>>> Ok, so how would userspace then can set those other informations?
> > >>>
> > >>> So to jump in the middle of the discussion but what other formats does
> > >>> the userspace would like to use? Afaik we only have PCM_s16le and
> > >>> transparent encoded data support so far.
> > >>
> > >> Hi Luiz! As I wrote above, e.g. bluetooth adapters in new Thinkpads
> > >> supports in-hardware mSBC encoding/decoding. So you need to say to
> > >> adapter if you want mSBC or PCM_s16le. Not "transparent". But it needs
> > >> to use "Enhanced Setup Synchronous Connection" call not just basic
> > >> "Setup Synchronous Connection". Structure which I defined above is just
> > >> copy of parameters which needs to be passed to "Enhanced Setup
> > >> Synchronous Connection" call.
> > >>
> > >
> > > Hello, can we move forward in this problem? If above my proposed API for
> > > setting codecs settings is not suitable, could you please propose
> > > different which would provide needed functionality?
> > >
> > > Because kernel is currently blocking usage of any other codec and
> > > therefore without fixing this issue it is not possible to use any other
> > > codec.
> > >
> > > Also kernel is blocking usage of hardware mSBC encoder and decoder which
> > > is part of bluetooth adapters (e.g. in new Thinkpads) so it is still
> > > needed to do whole encoding / decoding in software...
> >
> > the interface to the kernel needs to minimal. Tell it what you want and it tells you back what you got. Exposing a HCI command structure via ioctl is not the solution.
>
> Marcel, as I said in first email, to use one specific AuriStream codec,
> kernel needs to set following SCO properties:
>
> syncPktTypes = 0x003F
> bandwidth = 4000
> max_latency = 16
> voice_settings = 0x63
> retx_effort = 2
>
> And to use hardware encoder (e.g. mSBC), kernel needs to userspace allow
> to set all parameters for "Enhanced Setup Synchronous Connection" HCI
> command.
>
> Otherwise userspace cannot use hardware encoder/decoder.
>
> I do no know how to create more minimal interface as one which I
> proposed to allow usage of both AuriStream and also in-hardware
> encoders/decoders.
>
> If you do not like my proposed API for it, could you please show me
> different solution for API which would allow userspace applications
> (e.g. pulseaudio) to use AuriStream codec and also would be able to use
> in-hardware encoder/decoders? So pulseaudio would not have to use own
> software encoder/decoder when bluetooth adapter supports it in HW?
>
Hello! This is a friendly reminder that another month passed and this
issue is still open.
Now it is more then 9 months since I reported this problem that kernel
does not allow to setup SCO transport for AuriStream codec and I really
would like to move forward.
Could somebody help me what could I do to move forward and unblock
kernel to allow usage of additional SCO codecs and also to allow usage
of hardware mSBC encoder/decoder?
I'm starting to feel frustrated as it looks like it is ignored and I do
not see any way how can I continue and solve this problem.
In userspace I cannot do anything if kernel forbids to setup SCO
connection with custom parameters which are needed for other codecs.
Also I cannot do anything in userspace if kernel does not allow to use
in-hardware mSBC encoder/decoder, I cannot activate it from userspace.
--
Pali Rohár
[email protected]
Hello Marcel,
first thank you for reviewing Pali's work.
As I understood you'd like more minimal interface, but since Pali has been
working on bluetooth stack for really long and there is no better option,
would you be willing accept this code?
I know it may sounds like compromise, but no-one came with better solution
in given time.
In my opinion upstream can benefit from already (well) designed
and tested solution, than waiting for messaiah with possibly perfect solution
which doesn't exist yet (may never shows up).
Best regards
David Heidelberg
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[];
+};
+
__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.
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
Hi Pali,
On Sun, Apr 19, 2020 at 4:49 PM Pali Rohár <[email protected]> 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
--
Luiz Augusto von Dentz
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>
> On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <[email protected]> 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
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 <[email protected]> wrote:
>>
>> On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <[email protected]> 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 <[email protected]> wrote:
> >
> > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
> > >
> > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <[email protected]> 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.
--
Luiz Augusto von Dentz
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 <[email protected]> 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 <[email protected]> wrote:
> > > >
> > > > On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <[email protected]> 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
--
Ujjwal "Ryzokuken" Sharma (he/him)
Compilers Hacker, Node.js Core Collaborator and Speaker
Hi Ujjwal,
On Wed, May 27, 2020 at 5:19 AM Ujjwal Sharma <[email protected]> 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.
--
Luiz Augusto von Dentz
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
--
Ujjwal "Ryzokuken" Sharma (he/him)
Compilers Hacker, Node.js Core Collaborator and Speaker
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
What can we do to get this published?
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, 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 <[email protected]> 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.
--
Luiz Augusto von Dentz