[Bug 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221598

--- Comment #6 from Alexander Paderin (apocarteres@gmail.com) ---
Additional binary usbmon evidence
=================================

I captured the same HFP/mSBC failure with simultaneous btmon and binary usbmon.

New files:

```
captures/btmon-20260530-191225.snoop
captures/usbmon-bus3-dev7-ep3-20260530-191228.jsonl.gz
reports/captures-sco-analysis.md
reports/usbmon-bin-analysis.md
reports/usbmon-bin-anomalies.csv
```

The binary usbmon capture was taken from `/dev/usbmon3`, filtered to Bluetooth
device `3-007`, isochronous endpoint 3. It includes full ISO descriptors and
payload data, unlike the debugfs text usbmon log.

Important result:

```
usbmon-bus3-dev7-ep3-20260530-191228.jsonl.gz

RX USB IN completions:
  reconstructed ISO fragments: 12675 x 25 bytes
  reconstructed HCI SCO packets: 4225/4225 valid, handle 5
  H2/mSBC markers: 5038
  H2 bad sequence: 23
  H2 same sequence: 21
  H2 bad distance: 20

TX USB OUT submissions:
  reconstructed ISO fragments: 12669 x 25 bytes
  reconstructed HCI SCO packets: 4223/4223 valid, handle 5
  H2/mSBC markers: 5068
  H2 bad sequence: 0
  H2 same sequence: 0
  H2 bad distance: 0
```

The simultaneous btmon capture shows a matching RX-only problem:

```
btmon-20260530-191225.snoop

RX:
  packets: 3963 x dlen 72
  <1ms packet intervals: 20.0%
  >15ms packet intervals: 10.0%
  H2 bad sequence: 21
  H2 same sequence: 20
  H2 bad distance: 17

TX:
  packets: 3961 x dlen 72
  H2 bad sequence: 0
  H2 same sequence: 0
  H2 bad distance: 0
```

This suggests that the H2/mSBC sequence corruption is already visible in the
USB ISO IN data delivered to the host, before PipeWire/WirePlumber and before
userspace. It also makes the repeated near-identical btmon RX timestamps less
important by themselves: the USB IN side is batched in 10 ISO descriptors per
URB, so several 1 ms USB frames are naturally processed together by one URB
completion.

The remaining question appears to be whether the controller/firmware is
delivering duplicated/missing mSBC frames on RX, or whether the Linux
btusb/btrtl setup for this controller causes the controller to use bad SCO/eSCO
parameters. The next useful comparison would be a Windows USBPcap trace of the
same HFP/mSBC scenario, especially the vendor initialization commands, selected
USB alternate setting, and `Setup Synchronous Connection` parameters.

Attached archive: `bluetooth-rtl8821c-binary-usbmon-update-2026-05-30.tar.xz`

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.