Hi,
On Thu, Sep 14, 2017 at 05:00:16PM +0300, Luiz Augusto von Dentz wrote:
> On Thu, Sep 14, 2017 at 2:44 PM, Sebastian Reichel <sre at kernel.org> wrote:
> > Hi,
> >
> > Bose QC35 are affected by the attached upgrade notice
> > from Pulseaudio 11. The workaround fixes the problem.
>
> This doesn't make much sense when the problem below refer to the local
> adapter not the remote device, so I suspect just about any device
> would have similar problem when using an MTU not compatible with the
> adapter.
Sorry, I didn't look at this more detailed and thought this would be
dependent on the remote device. I only tested the QC35, so all other
headsets may also be broken with the adapter now. The adapter is this
one:
{ USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL },
-- Sebastian
> Or perhaps this does depend on the packet type the controller
> end up negotiating since the spec say:
>
>
> 6.5.2.1 HV1 Packet
> The HV1 packet has 10 information bytes. The bytes are protected with a rate
> 1/3 FEC. No MIC is present. No CRC is present. The payload length is fixed at
> 240 bits. There is no payload header present.
> 6.5.2.2 HV2 Packet
> The HV2 packet has 20 information bytes. The bytes are protected with a rate
> 2/3 FEC. No MIC is present. No CRC is present. The payload length is fixed at
> 240 bits. There is no payload header present.
> can 6.5.2.3 HV3 Packet
> The HV3 packet has 30 information bytes. The bytes are not protected by FEC.
> No MIC is present. No CRC is present. The payload length is fixed at 240 bits.
> There is no payload header present.
>
> So HV1, HV2, HV3 packet size is 240bit = 48 bytes, but for EV and eSCO
> the payload is not fixed. So far we had assumed the controller would
> do the flow control so we just push data to its buffer but if it does
> expect the exact payload depending on the packet type that would
> explain why this doesn't work all the time. I have never seem a SCO
> buffer over 96 bytes and since packets but packets such as 3-EV5 can
> take up to 540 bytes of payload, well I guess we will need to ask the
> controller folks how they are handling SCO over HCI because the spec
> is not very clear about it.
>
> > -- Sebastian
> >
> >> https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/
> >>
> >> Improved bluetooth MTU configuration
> >>
> >> The packet size (a.k.a. MTU, "maximum transmission unit") that
> >> PulseAudio uses with the bluetooth HSP profile was previously
> >> always configured to be 48 bytes. That worked with most hardware,
> >> but some adapters require a different packet size. Now PulseAudio
> >> asks the kernel what packet size should be used, which fixes the
> >> problem.
> >>
> >> However, a new problem appeared: some adapters that used to work
> >> with 48 byte packet size don't any more work with the size that
> >> the kernel tells PulseAudio to use. If you find that HSP audio
> >> stopped working when upgrading to PulseAudio 11.0, you can revert
> >> to the old behaviour by passing option "autodetect_mtu=no" to
> >> module-bluetooth-discover in /etc/pulse/default.pa. If that fixes
> >> the problem, then please report the problem to the BlueZ and/or
> >> PulseAudio developers, so that the kernel can be fixed.
>
>
>
> --
> Luiz Augusto von Dentz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170914/d8f293a1/attachment.sig>
