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

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

[bugzilla-daemon]

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

            Bug ID: 221598
           Summary: Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC
                    microphone stutters with bursty SCO RX delivery
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.12.90+deb13.1-rt-amd64, 6.12.90+deb13-amd64,
                    6.19.10-300.fc44.x86_64
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: apocarteres@gmail.com
        Regression: No

Created attachment 310210
  --> https://bugzilla.kernel.org/attachment.cgi?id=310210&action=edit
btsnoop captures and report draft

I am seeing severe HFP/mSBC microphone stutter with a Realtek RTL8821C
Bluetooth USB controller on Linux. The same PC and the same Bluetooth headsets
work correctly under Windows 11.

The problem reproduces on both Debian and Fedora live systems, so it does not
look specific to one distribution audio stack.

### Hardware

Bluetooth controller:

```
Bus 003 Device 007: ID 0bda:c821 Realtek Semiconductor Corp. Bluetooth Radio
Negotiated speed: Full Speed (12Mbps)
```

Controller details from Linux:

```
hci0: Type: Primary  Bus: USB
BD Address: 64:57:25:4C:4E:BA
HCI Version: 4.2 (0x8)  Revision: 0x75b8
LMP Version: 4.2 (0x8)  Subversion: 0xf098
Manufacturer: Realtek Semiconductor Corporation (93)
```

Kernel log during initialization:

```
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08
lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
```

Headsets tested:

- JBL TOUR ONE M2
- Jabra headset, exact model unknown

Both headsets show the same problem on Linux and work normally on Windows 11 on
the same machine.

### Software tested

Debian:

```
Linux dev 6.12.90+deb13.1-rt-amd64 #1 SMP PREEMPT_RT Debian 6.12.90-2
(2026-05-27) x86_64 GNU/Linux
bluez 5.82-1.1
pipewire 1.4.2-1
wireplumber 0.5.8-2
firmware-realtek 20250410-2
```

The same issue was also reproduced on the non-RT Debian 6.12.90 kernel.

Fedora live:

```
Linux version 6.19.10-300.fc44.x86_64
Bluetooth subsystem version 2.22
```

The Fedora capture was made from a live Fedora Workstation 44 system.

### Actual behavior

In HFP/mSBC mode the microphone audio has severe stutter, dropouts and "jerky"
timing. Applications receive very poor audio. PipeWire/WirePlumber logs
repeated mSBC decode failures:

```
wireplumber: spa.bluez5.source.sco: decode failed: -3
```

Switching to CVSD avoids the mSBC decoder errors but the microphone still
stutters and the audio quality is too low to be useful.

### Expected behavior

The HFP microphone should work without dropouts, as it does on the same machine
and the same headsets under Windows 11.

### eSCO / mSBC negotiation

The btsnoop captures show eSCO with transparent air coding and 60 byte RX/TX
packet lengths. Example from the Fedora capture:

```
Setup Synchronous Connection:
  Tx/Rx bandwidth: 8000
  Max latency: 13
  Air Coding Format: Transparent Data
  Retransmission effort: Optimize for link quality

Synchronous Connect Complete:
  Link type: eSCO
  Transmission interval: 0x0c
  Retransmission window: 0x06
  RX packet length: 60
  TX packet length: 60
  Air mode: Transparent
```

The actual SCO packets in the captures are 72 byte packets:

```
SCO Data RX: Handle 2 flags 0x00 dlen 72
SCO Data TX: Handle 2 flags 0x00 dlen 72
```

### Capture timing summary

The relevant pattern is that incoming SCO packets are delivered in bursts:
about 20% of RX inter-arrival times are below 1 ms, followed by regular long
gaps above 15 ms. This is visible on both Debian and Fedora. TX timing is much
smoother and does not show the same sub-1 ms burst pattern in most captures.

Timing was computed from `btmon -r <capture>` timestamps for `SCO Data RX/TX`
lines.

```
Debian, bt-sco-bad.snoop:
  RX n=1765 dlen=72 avg=9.003 ms min=0.001 max=20.154 lt1ms=20.0% gt15ms=10.0%
gt20ms=5.2%
  TX n=1765 dlen=72 avg=8.998 ms min=0.022 max=21.657 lt1ms=9.2%  gt15ms=8.1% 
gt20ms=4.9%

Debian, bt-sco-bad1.snoop:
  RX n=3069 dlen=72 avg=9.000 ms min=0.001 max=20.166 lt1ms=20.0% gt15ms=10.0%
gt20ms=4.2%
  TX n=3066 dlen=72 avg=9.000 ms min=0.024 max=21.590 lt1ms=3.8%  gt15ms=12.7%
gt20ms=2.2%

Debian, bt-sco-bad2.snoop:
  RX n=1943 dlen=72 avg=8.996 ms min=0.002 max=20.136 lt1ms=20.2% gt15ms=10.2%
gt20ms=6.0%
  TX n=1942 dlen=72 avg=8.999 ms min=5.016 max=16.256 lt1ms=0.0%  gt15ms=16.2%
gt20ms=0.0%

Debian, bt-sco-bad3.snoop:
  RX n=1850 dlen=72 avg=9.000 ms min=0.001 max=20.102 lt1ms=20.3% gt15ms=10.3%
gt20ms=1.8%
  TX n=1850 dlen=72 avg=8.997 ms min=3.788 max=16.241 lt1ms=0.0%  gt15ms=16.2%
gt20ms=0.0%

Debian, bt-sco-bad4.snoop:
  RX n=5600 dlen=72 avg=9.000 ms min=0.001 max=20.159 lt1ms=20.0% gt15ms=10.0%
gt20ms=5.3%
  TX n=5597 dlen=72 avg=9.000 ms min=4.876 max=16.386 lt1ms=0.0%  gt15ms=16.2%
gt20ms=0.0%

Fedora live, fedora.cap:
  RX n=2089 dlen=72 avg=8.249 ms min=0.001 max=18.447 lt1ms=20.0% gt15ms=10.0%
gt18ms=10.0%
  TX n=1914 dlen=72 avg=8.998 ms min=6.215 max=15.234 lt1ms=0.0%  gt15ms=10.6%
```

### Things already tested

- Same Bluetooth adapter and headsets work correctly on Windows 11.
- Reproduced with two different Bluetooth headsets.
- Reproduced on Debian 6.12 and Fedora live 6.19.
- Disabled USB autosuspend for `btusb`:

```
/sys/module/btusb/parameters/enable_autosuspend = N
```

- Unloaded/blacklisted the Wi-Fi side of the combo device (`rtw88_8821ce`): no
fix.
- Disabled nearby USB audio/camera devices on the same USB bus: no fix.
- Tried Debian PREEMPT_RT kernel: no fix.
- Tried `btusb force_scofix=1`: worse.
- Tried `btusb disable_scofix=1`: worse.
- Tried `btusb reset=0`: no durable fix.
- Tried disabling eSCO with `bluetooth.disable_esco=1`: microphone became
unavailable.
- Tried PipeWire/WirePlumber SCO/mSBC workarounds, including CVSD and hardware
offload experiments: no useful fix.

Current relevant module parameters:

```
/sys/module/bluetooth/parameters/disable_ertm = N
/sys/module/bluetooth/parameters/disable_esco = N
/sys/module/bluetooth/parameters/enable_ecred = Y
/sys/module/btusb/parameters/reset = Y
/sys/module/btusb/parameters/force_scofix = N
/sys/module/btusb/parameters/disable_scofix = N
/sys/module/btusb/parameters/enable_autosuspend = N
```

### Possibly related upstream reports / patches

This looks related to the Realtek SCO/WBS path in `btusb`/`btrtl`.

A very similar Realtek patch was posted but does not appear to be merged:

```
[PATCH v5] Bluetooth: btusb: Work around spotty SCO quality
https://patchew.org/linux/20221226074829.8682-1-hildawu%40realtek.com/
```

That patch targeted other Realtek USB IDs (`0bda:8771`, `0bda:8773`,
`0bda:8871`, `0bda:8873`), not `0bda:c821`, but the symptom family is close:
Realtek USB Bluetooth, WBS/SCO, spotty SCO quality, and packet handling around
WBS.

Possibly related Bugzilla entries:

```
Bug 219997 - [rtw89] Headset unusable because of delays and stutter
https://bugzilla.kernel.org/show_bug.cgi?id=219997

Bug 219992 - Linux logs warning `Bluetooth: hci0: SCO packet for unknown
connection handle 3`
https://bugzilla.kernel.org/show_bug.cgi?id=219992
```

These do not seem to be exact matches for this controller (`0bda:c821` /
RTL8821C), but they may be related to the same SCO/WBS area.

### Attachments available

The following captures are available and should be attached:

```
/home/apocarteres/bt-sco-bad.snoop
/home/apocarteres/bt-sco-bad1.snoop
/home/apocarteres/bt-sco-bad2.snoop
/home/apocarteres/bt-sco-bad3.snoop
/home/apocarteres/bt-sco-bad4.snoop
/opt/fedora.cap
```

Recommended minimum attachments:

```
/home/apocarteres/bt-sco-bad4.snoop
/opt/fedora.cap
```

`bt-sco-bad4.snoop` is a longer Debian capture. `fedora.cap` demonstrates that
the same bursty SCO RX pattern also happens on Fedora 6.19.

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

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

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

[bugzilla-daemon]

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

--- Comment #1 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310211
  --> https://bugzilla.kernel.org/attachment.cgi?id=310211&action=edit
btsnoop captures and report draft

Archive contains the Debian and Fedora btsnoop captures referenced in the
report, plus the local report draft.

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

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

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

[bugzilla-daemon]

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

Alexander Paderin (apocarteres@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #310211|0                           |1
        is obsolete|                            |

--- Comment #2 from Alexander Paderin (apocarteres@gmail.com) ---
Comment on attachment 310211
  --> https://bugzilla.kernel.org/attachment.cgi?id=310211
btsnoop captures and report draft

Marking this attachment obsolete because it is a duplicate of attachment
310210.

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

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

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

[bugzilla-daemon]

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

--- Comment #3 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310212
  --> https://bugzilla.kernel.org/attachment.cgi?id=310212&action=edit
btmon capture on Debian (RT)

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

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

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

[bugzilla-daemon]

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

--- Comment #4 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310213
  --> https://bugzilla.kernel.org/attachment.cgi?id=310213&action=edit
btmon capture on Fedora Live

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

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

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

[bugzilla-daemon]

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

Alexander Paderin (apocarteres@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|All                         |Intel

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

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

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

[bugzilla-daemon]

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

--- Comment #5 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310214
  --> https://bugzilla.kernel.org/attachment.cgi?id=310214&action=edit
binary usbmon SCO/H2 analysis update

Archive with simultaneous btmon capture, binary usbmon JSONL.GZ capture,
analysis reports and scripts.

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

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

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #7 from Alexander Paderin (apocarteres@gmail.com) ---
Additional update after isolating user-space HCI traffic:

I found a strong practical mitigation/confounder: stopping/removing Blueman
significantly improves the HFP/mSBC microphone quality on this machine.

Before this test, Blueman UI processes were running:

- `blueman-manager`
- `blueman-applet`
- `blueman-tray`

The bad traces with Blueman running contained frequent HCI control traffic,
especially:

- `Read RSSI` (`0x1405`)
- `Read Transmit Power Level` (`0x0c2d`)

After stopping/removing Blueman, the same headset/machine produced much cleaner
captures. The subjective microphone stutter also became noticeably better.

Summary of RX mSBC/H2 continuity results:

| run | extra HCI polling | RX H2 markers | bad seq | bad seq/k | bad dist |
bad dist/k |
|---|---:|---:|---:|---:|---:|---:|
| old control | yes | 3486 | 21 | 6.02 | 23 | 6.60 |
| no-Blueman control 1 | no | 4301 | 6 | 1.39 | 15 | 3.49 |
| no-Blueman control 2 | no | 4312 | 6 | 1.39 | 6 | 1.39 |
| bad noisy watch-only run | yes | 3949 | 454 | 114.97 | 425 | 107.62 |
| bad noisy raw-open repeat | yes | 4812 | 453 | 94.14 | 385 | 80.01 |

TX remained clean in all runs (`bad_sequence=0`, `bad_distance=0`).

Important caveat: I then tried to reproduce the issue without Blueman by
injecting the same polling manually after eSCO setup. The stress script sent 25
pairs of:

- `Read RSSI` (`0x1405`)
- `Read Transmit Power Level` (`0x0c2d`)

That did not reproduce the catastrophic bad runs:

| run | polling | RX H2 markers | bad seq | bad seq/k | bad dist | bad dist/k |
|---|---:|---:|---:|---:|---:|---:|
| no-Blueman control 2 | no | 4312 | 6 | 1.39 | 6 | 1.39 |
| artificial HCI polling stress | 25 RSSI + 25 TX-power reads | 3778 | 16 |
4.24 | 13 | 3.44 |

So `Read RSSI` / `Read Transmit Power Level` alone is not proven to be the
direct root cause. The stronger conclusion is:

- Removing Blueman is a real practical mitigation on this RTL8821C/0bda:c821
system.
- Extra user-space HCI management/control traffic is a strong confounder and
can correlate with much worse RX mSBC continuity.
- The underlying failure still appears to be RX-only H2/mSBC continuity loss:
host TX stays clean, eSCO setup parameters remain normal, and RX still has some
breaks even in the clean no-Blueman baseline.

Relevant local captures/reports:

- `captures/sco-control-test-20260531-002158.snoop`
- `captures/sco-control-test-20260531-002431.snoop`
- `captures/hci-poll-stress-test-20260531-003222.snoop`
- `reports/control-no-blueman-20260531-002158-findings.md`
- `reports/control-no-blueman-repeat-20260531-002431-findings.md`
- `reports/hci-poll-stress-20260531-003222-findings.md`

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

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