Hello,
We currently have an opened merge request on adding mSBC support to PulseAudio.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/254
There currently seems to be an issue in getting the correct MTU. In the test
setup it works with the ofono backend, except for the assumed MTU. For getting
it to work, we had to use a MTU of 24. 48 does not work and renders silence.
getsockopt(card->fd, SOL_SCO, SCO_OPTIONS ... returns 64 which is too large.
The missing bits on the kernel side seems to be the below patch.
https://lore.kernel.org/patchwork/patch/1303411/
Second patch in the above series seem to have been applied but not the first.
The first patch in the series above, when applied seems to fix getsockopt
returning 24 bytes for the MTU. An additional correction on top of that
below
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index fd0dcfa9a390..35f9c0743014 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1669,6 +1669,8 @@ static int btusb_switch_alt_setting(struct hci_dev *hdev, int new_alts)
err = __set_isoc_interface(hdev, new_alts);
if (err < 0)
return err;
+
+ hdev->sco_mtu = hci_packet_size_usb_alt[new_alts];
}
if (!test_and_set_bit(BTUSB_ISOC_RUNNING, &data->flags)) {
seems to make it work for all bluetooth usb devices.
Has there been any further development or way to push this forward?
- Sanchayan.
On Fri, Feb 5, 2021 at 6:52 PM Sanchayan <[email protected]> wrote:
>
> Hello,
>
> We currently have an opened merge request on adding mSBC support to PulseAudio.
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/254
>
> There currently seems to be an issue in getting the correct MTU. In the test
> setup it works with the ofono backend, except for the assumed MTU. For getting
> it to work, we had to use a MTU of 24. 48 does not work and renders silence.
> getsockopt(card->fd, SOL_SCO, SCO_OPTIONS ... returns 64 which is too large.
>
> The missing bits on the kernel side seems to be the below patch.
> https://lore.kernel.org/patchwork/patch/1303411/
>
> Second patch in the above series seem to have been applied but not the first.
>
> The first patch in the series above, when applied seems to fix getsockopt
> returning 24 bytes for the MTU. An additional correction on top of that
> below
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index fd0dcfa9a390..35f9c0743014 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -1669,6 +1669,8 @@ static int btusb_switch_alt_setting(struct hci_dev *hdev, int new_alts)
> err = __set_isoc_interface(hdev, new_alts);
> if (err < 0)
> return err;
> +
> + hdev->sco_mtu = hci_packet_size_usb_alt[new_alts];
> }
>
> if (!test_and_set_bit(BTUSB_ISOC_RUNNING, &data->flags)) {
>
>
> seems to make it work for all bluetooth usb devices.
>
> Has there been any further development or way to push this forward?
>
> - Sanchayan.
Gentle reminder, anything can be done to push this forward?
I believe we all use the same workaround discussed in patchwork
thread https://lore.kernel.org/patchwork/patch/1303411/ but first SCO
socket write either has to be delayed until first read succeeds, or first
SCO socket write size may be incorrect since payload size of HCI
packet is not propagated to socket MTU value.
With https://lore.kernel.org/patchwork/patch/1303411/ and the change
above to btusb_switch_alt_setting() first SCO socket write can be done
with correct size right away.
--
Kind regards,
Igor V. Kovalenko