Hi all,
PulseAudio recently started to use
getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
read_mtu = sco_opt.mtu;
write_mtu = sco_opt.mtu;
to query the MTU of the SCO socket. Previously we used a fixed value of
48, but that didn't work for some bluetooth chipsets (see the commit
message[1]). Now, however, it was reported[2] that the new code doesn't
work on some hardware where the old fixed MTU used to work.
What is PulseAudio expected to do? We will have to add an option for
configuring the MTU for now, but that's not a real solution, because
users can't be expected to figure out that they need to fiddle with the
MTU if HSP audio doesn't work. Is this a kernel bug? When this new code
in PulseAudio gets more widely used and starts breaking people's
bluetooth audio, should I tell the users to send bug reports to this
mailing list? Or should PulseAudio keep using a fixed MTU, unless
configured otherwise?
[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=fb6b8dfdec2df39c055f98266aa1eb75e8ebfb1c
[2] https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027408.html
--
Tanu
https://www.patreon.com/tanuk
Hello,
Sorry to butt in but I have some observations on this.
I have been working on a related thing
(https://github.com/Arkq/bluez-alsa) to add support for HFP and mSBC.
HW:
CSR8510 A10 dongle
Jabra Halo Smart and LG HBS730
SW:
Kernel: 4.4.0-53-generic #74-Ubuntu
BlueZ 5.43
On Fri, Feb 10, 2017 at 3:48 AM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Tanu,
>
>>>> PulseAudio recently started to use
>>>>
>>>> getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
>>>> read_mtu =3D sco_opt.mtu;
>>>> write_mtu =3D sco_opt.mtu;
>>>>
>>>> to query the MTU of the SCO socket. Previously we used a fixed value o=
f
>>>> 48, but that didn't work for some bluetooth chipsets (see the commit
>>>> message[1]). Now, however, it was reported[2] that the new code doesn'=
t
>>>> work on some hardware where the old fixed MTU used to work.
>>>
>>> can you share details here and btmon traces for the data buffer sizes
>>> and the USB descriptor details. We would need to figure out where
>>> this goes wrong and maybe introduce some driver quirks to ensure that
>>> it returns usable values.
>>
>> Georg already provided a btmon dump. Did that contain everything you
>> need? The way you put your words, it's not clear to me if the USB
>> descriptor details are included in the btmon output or is the USB
>> descriptor a separate thing?
>>
>> I'd like to provide clear instructions for users to get the necessary
>> information, in case it turns out that Georg is not the only one with
>> this problem. What options should be given to btmon?
>
> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0
>> HCI Event: Command Complete (0x0e) plen 12
> Read Local Version Information (0x04|0x0001) ncmd 1
> Status: Success (0x00)
> HCI version: Bluetooth 2.0 (0x03) - Revision 5276 (0x149c)
> LMP version: Bluetooth 2.0 (0x03) - Subversion 5276 (0x149c)
> Manufacturer: Cambridge Silicon Radio (10)
> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0
>> HCI Event: Command Complete (0x0e) plen 10
> Read BD ADDR (0x04|0x0009) ncmd 1
> Status: Success (0x00)
> Address: 00:15:83:73:FD:06 (IVT corporation)
> < HCI Command: Read Buffer Size (0x04|0x0005) plen 0
>> HCI Event: Command Complete (0x0e) plen 11
> Read Buffer Size (0x04|0x0005) ncmd 1
> Status: Success (0x00)
> ACL MTU: 384 ACL max packet: 8
> SCO MTU: 64 SCO max packet: 8
>
> This seems to be CSR based hardware. Can we verify that this is the case =
with the /sys/kernel/debug/usb/devices info for this device. If this is a f=
ake device, then all bets are off anyway.
I am using this:
T: Bus=3D02 Lev=3D02 Prnt=3D02 Port=3D03 Cnt=3D01 Dev#=3D 30 Spd=3D12 Mx=
Ch=3D 0
D: Ver=3D 2.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1
P: Vendor=3D0a12 ProdID=3D0001 Rev=3D88.91
S: Product=3DCSR8510 A10
C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D100mA
I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms
E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms
E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms
I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms
I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms
I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms
I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms
I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms
I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver=
=3Dbtusb
E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms
E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms
No idea if it is real or not though. I should have a Broadcom dongle
around somewhere, I will see how it behaves.
>
> And yes, it reports 64 octets for the MTU. Which is most likely what you =
are getting back from the SCO socket. If this is all bogus and doesn=E2=80=
=99t work for CSR devices, we need to quirk it in the btusb driver to repor=
t a different value.
What I am seeing is that the HCI device shows SCO MTU of 64 bytes,
while the SCO connection request/response indicates a 60 byte payload
size:
hci0: Type: Primary Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:290561090 acl:5745 sco:6560504 events:7731 errors:0
TX bytes:63087159 acl:4785 sco:6783105 commands:1870 errors:2596
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
[hci0] 31.193820
Handle: 69
Transmit bandwidth: 8000
Receive bandwidth: 8000
Max latency: 10
Setting: 0x0060
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: CVSD
Retransmission effort: Optimize for power consumption (0x01)
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 =
=
=
[hci0] 31.196366
Setup Synchronous Connection (0x01|0x0028) ncmd 1
Status: Success (0x00)
> HCI Event: Max Slots Change (0x1b) plen 3 =
=
=
[hci0] 31.203367
Handle: 69
Max slots: 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17 =
=
=
[hci0] 31.208364
Status: Success (0x00)
Handle: 71
Address: 00:18:6B:52:A6:3F (Sambu Communics CO., LTD.)
Link type: eSCO (0x02)
Transmission interval: 0x0c
Retransmission window: 0x02
RX packet length: 60
TX packet length: 60
Air mode: CVSD (0x02)
....
However, for CVSD audio I also am getting 48 byte PDUs from the socket
(btmon shows same size) but if I configure the SCO link in to
transparent mode for mSBC I start getting 24 byte PDUs (again btmon
shows 24 bytes as well). In both cases the bandwidth is the same 8000
kByte/s.
> SCO Data RX: Handle 71 flags 0x00 dlen 48 =
=
=
[hci0] 31.234743
> SCO Data RX: Handle 71 flags 0x00 dlen 48 =
=
=
[hci0] 31.234744
In either case, if I actually send 60 or 64 byte PDUs, I hear nothing.
As a workaround I am setting the write MTU based on the read MTU I get
from the SCO socket and that seems reliable.
(As a side note, I have not been able to make the mSBC output work, no
headset of mine plays anything I send and I am pretty sure I have the
framing correct. I will try another controller for this as well.)
- Juha
On 10.02.2017 12:48, Marcel Holtmann wrote:
> Hi Tanu,
>
>>>> PulseAudio recently started to use
>>>>
>>>> getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
>>>> read_mtu = sco_opt.mtu;
>>>> write_mtu = sco_opt.mtu;
>>>>
>>>> to query the MTU of the SCO socket. Previously we used a fixed value of
>>>> 48, but that didn't work for some bluetooth chipsets (see the commit
>>>> message[1]). Now, however, it was reported[2] that the new code doesn't
>>>> work on some hardware where the old fixed MTU used to work.
>>> can you share details here and btmon traces for the data buffer sizes
>>> and the USB descriptor details. We would need to figure out where
>>> this goes wrong and maybe introduce some driver quirks to ensure that
>>> it returns usable values.
>> Georg already provided a btmon dump. Did that contain everything you
>> need? The way you put your words, it's not clear to me if the USB
>> descriptor details are included in the btmon output or is the USB
>> descriptor a separate thing?
>>
>> I'd like to provide clear instructions for users to get the necessary
>> information, in case it turns out that Georg is not the only one with
>> this problem. What options should be given to btmon?
> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0
>> HCI Event: Command Complete (0x0e) plen 12
> Read Local Version Information (0x04|0x0001) ncmd 1
> Status: Success (0x00)
> HCI version: Bluetooth 2.0 (0x03) - Revision 5276 (0x149c)
> LMP version: Bluetooth 2.0 (0x03) - Subversion 5276 (0x149c)
> Manufacturer: Cambridge Silicon Radio (10)
> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0
>> HCI Event: Command Complete (0x0e) plen 10
> Read BD ADDR (0x04|0x0009) ncmd 1
> Status: Success (0x00)
> Address: 00:15:83:73:FD:06 (IVT corporation)
> < HCI Command: Read Buffer Size (0x04|0x0005) plen 0
>> HCI Event: Command Complete (0x0e) plen 11
> Read Buffer Size (0x04|0x0005) ncmd 1
> Status: Success (0x00)
> ACL MTU: 384 ACL max packet: 8
> SCO MTU: 64 SCO max packet: 8
>
> This seems to be CSR based hardware. Can we verify that this is the case with the /sys/kernel/debug/usb/devices info for this device. If this is a fake device, then all bets are off anyway.
>
> And yes, it reports 64 octets for the MTU. Which is most likely what you are getting back from the SCO socket. If this is all bogus and doesn’t work for CSR devices, we need to quirk it in the btusb driver to report a different value.
>
> As a side note, a newer btmon version will decode all the Unknown packet entries.
>
> Regards
>
> Marcel
>
Hi Marcel,
I don't have /sys/kernel/debug/usb/devices, but lsusb -v also gives a
lot of information.
It is indeed a CSR device, I have two of them in my system (different
dongles but both CSR),
not sure which is the one the headset connects to. I attached the lsusb
output.
Regards
Georg
Hi Tanu,
>>> PulseAudio recently started to use
>>>
>>> getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
>>> read_mtu = sco_opt.mtu;
>>> write_mtu = sco_opt.mtu;
>>>
>>> to query the MTU of the SCO socket. Previously we used a fixed value of
>>> 48, but that didn't work for some bluetooth chipsets (see the commit
>>> message[1]). Now, however, it was reported[2] that the new code doesn't
>>> work on some hardware where the old fixed MTU used to work.
>>
>> can you share details here and btmon traces for the data buffer sizes
>> and the USB descriptor details. We would need to figure out where
>> this goes wrong and maybe introduce some driver quirks to ensure that
>> it returns usable values.
>
> Georg already provided a btmon dump. Did that contain everything you
> need? The way you put your words, it's not clear to me if the USB
> descriptor details are included in the btmon output or is the USB
> descriptor a separate thing?
>
> I'd like to provide clear instructions for users to get the necessary
> information, in case it turns out that Georg is not the only one with
> this problem. What options should be given to btmon?
< HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 2.0 (0x03) - Revision 5276 (0x149c)
LMP version: Bluetooth 2.0 (0x03) - Subversion 5276 (0x149c)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
Status: Success (0x00)
Address: 00:15:83:73:FD:06 (IVT corporation)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 1
Status: Success (0x00)
ACL MTU: 384 ACL max packet: 8
SCO MTU: 64 SCO max packet: 8
This seems to be CSR based hardware. Can we verify that this is the case with the /sys/kernel/debug/usb/devices info for this device. If this is a fake device, then all bets are off anyway.
And yes, it reports 64 octets for the MTU. Which is most likely what you are getting back from the SCO socket. If this is all bogus and doesn’t work for CSR devices, we need to quirk it in the btusb driver to report a different value.
As a side note, a newer btmon version will decode all the Unknown packet entries.
Regards
Marcel
On Wed, 2017-02-01 at 20:47 +0100, Marcel Holtmann wrote:
> Hi Tanu,
>
> > PulseAudio recently started to use
> >
> > getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
> > read_mtu = sco_opt.mtu;
> > write_mtu = sco_opt.mtu;
> >
> > to query the MTU of the SCO socket. Previously we used a fixed value of
> > 48, but that didn't work for some bluetooth chipsets (see the commit
> > message[1]). Now, however, it was reported[2] that the new code doesn't
> > work on some hardware where the old fixed MTU used to work.
>
> can you share details here and btmon traces for the data buffer sizes
> and the USB descriptor details. We would need to figure out where
> this goes wrong and maybe introduce some driver quirks to ensure that
> it returns usable values.
Georg already provided a btmon dump. Did that contain everything you
need? The way you put your words, it's not clear to me if the USB
descriptor details are included in the btmon output or is the USB
descriptor a separate thing?
I'd like to provide clear instructions for users to get the necessary
information, in case it turns out that Georg is not the only one with
this problem. What options should be given to btmon?
--
Tanu
https://www.patreon.com/tanuk
On 01.02.2017 20:47, Marcel Holtmann wrote:
> Hi Tanu,
>
>> PulseAudio recently started to use
>>
>> getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
>> read_mtu = sco_opt.mtu;
>> write_mtu = sco_opt.mtu;
>>
>> to query the MTU of the SCO socket. Previously we used a fixed value of
>> 48, but that didn't work for some bluetooth chipsets (see the commit
>> message[1]). Now, however, it was reported[2] that the new code doesn't
>> work on some hardware where the old fixed MTU used to work.
> can you share details here and btmon traces for the data buffer sizes and the USB descriptor details. We would need to figure out where this goes wrong and maybe introduce some driver quirks to ensure that it returns usable values.
>
> Regards
>
> Marcel
>
Hi Marcel,
attached you find the btmon trace. The headset connects OK, so
this is just what happens when I try to play back something to the
HSP sink. The symptom is that I cannot hear anything and the
headset disconnects after a while. Maybe this is a bug in the headset?
The device is a Plantronics Backbeat Pro, I have the same issue with
an older 590Plantronics. Recording works, but I see in the trace
that recording still uses an MTU of 48.
Let me know if you need more information.
Regards
Georg
Hi Tanu,
> PulseAudio recently started to use
>
> getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
> read_mtu = sco_opt.mtu;
> write_mtu = sco_opt.mtu;
>
> to query the MTU of the SCO socket. Previously we used a fixed value of
> 48, but that didn't work for some bluetooth chipsets (see the commit
> message[1]). Now, however, it was reported[2] that the new code doesn't
> work on some hardware where the old fixed MTU used to work.
can you share details here and btmon traces for the data buffer sizes and the USB descriptor details. We would need to figure out where this goes wrong and maybe introduce some driver quirks to ensure that it returns usable values.
Regards
Marcel