Re: xHCI TT: FS audio capture glitches when btusb SCO runs concurrently

Hi Mathias,

thanks for the recipe. I captured both cases exactly as described
(dynamic debug for xhci_hcd + usbcore, xhci-hcd trace events,
81920 kB buffer), on the same kernel 7.1.3-1-default, during an
active mSBC HFP call each time, ~60-90 s per run. This time the
failing setup was the second environment from my original report
(Sennheiser FS combo headset [1395:0024] behind a Lenovo dock hub);
the clean run is the same headset moved to a direct root port
(usb-0000:00:14.0-2). Audible symptom matched previous findings:
uplink severely robotic behind the dock, clean on the root port
(downlink was clean in both runs this time).

Summary of the captures:

                             failing (behind dock)   clean (root port)
   trace Underrun events            2596                    0
   trace Missed events              3018                    0
   dmesg "Miss service
     interval error"                2219                    0
   trace isoc entries             368979                 361875 
(similar load)

The errors concentrate on exactly the two devices/endpoints involved:

- slot 39 = Sennheiser behind the dock TT:
     "Miss service interval error ... set skip flag"
     4090x on ep index 4 (EP2 IN  - the isoc capture endpoint),
      234x on ep index 1 (EP1 OUT - the isoc playback endpoint)
   (interleaved with "Found td. Clear skip flag" lines)

- slot 4 = Intel 8265 Bluetooth controller on root port 7 (1-7):
     "Underrun event on slot 4 ep 5"
     1884x on ep index 5 (EP3 OUT - the SCO isoc OUT endpoint)

Excerpt from the failing dmesg (first lines after the call went up):

   [58827.830235] xhci_hcd 0000:00:14.0: Underrun event on slot 4 ep 5
   [58827.830635] xhci_hcd 0000:00:14.0: Found td. Clear skip flag for 
slot 39 ep 4.
   [58827.833216] xhci_hcd 0000:00:14.0: Miss service interval error for 
slot 39 ep 4, set skip flag
   [58827.833699] xhci_hcd 0000:00:14.0: Found td. Clear skip flag for 
slot 39 ep 4.
   [58827.850113] xhci_hcd 0000:00:14.0: Miss service interval error for 
slot 39 ep 4, set skip flag
   [58827.876134] xhci_hcd 0000:00:14.0: Underrun event on slot 4 ep 5

Both error types run continuously for the whole duration of the call
(~90 s, first 58827.8, last 58916.9) and disappear completely when the
same headset is on the root port -- zero Underrun/Missed/MSIE events in
the clean run at comparable isoc traffic volume.

So during the call the xHC misses service intervals on the FS capture
stream behind the TT (matching the audible capture glitches from my
report) and at the same time hits ring underruns on the Bluetooth SCO
isoc OUT endpoint. The ep-index-to-endpoint mapping above is my
reading of xhci_get_endpoint_index(); please correct me if I misread.

Attached (xz):
- 12_failing_dock_dmesg.txt.xz      (32 kB)
- 12_failing_dock_xhci_trace.txt.xz (13 MB, full trace)
- 12_ok_rootport_dmesg.txt.xz       (9 kB)
- 12_ok_rootport_xhci_trace.txt.xz  (13 MB, full trace)

If the large attachments arrive as download links, that is my mail
server converting them; tell me if you prefer a different way to get
the full traces.

Next I will test the two isoc scheduling patches you pointed to and
report back:
https://lore.kernel.org/linux-usb/[email protected]/
https://lore.kernel.org/linux-usb/[email protected]/

Best regards,
Branislav Klocok

-- 
Branislav Klocok
email: [email protected]
tel: +421908703366

Dňa 28. 7. 2026 o 9:41 Mathias Nyman napísal(a):
> Hi
> 
> Back from vacation
> 
> On 7/18/26 13:18, Branislav Klocok wrote:
>> Hi,
>>
>> I'd like to report (and ask for guidance on) an apparent conflict between
>> two concurrent full-speed isochronous streams on the same xHCI 
>> controller:
>> a full-speed USB audio device behind a hub (split transactions through 
>> the
>> hub's TT) and the SCO endpoints of an Intel Bluetooth controller (btusb)
>> on a root port.
>>
>> Short version: while an HFP call is active over Bluetooth (SCO), the
>> capture stream of a full-speed USB headset plugged in *behind a dock hub*
>> is subtly corrupted. After mSBC encoding and the telephony path, the far
>> end hears severely "robotic" audio. Moving the same headset to a direct
>> root port makes the problem disappear immediately; moving it back behind
>> the dock brings it back. CVSD calls are perceptually unaffected.
>>
>> Environment
>> -----------
>> - ThinkPad X1 Carbon 6th gen; xHCI: Intel Sunrise Point-LP [8086:9d2f]
>> - Kernel 7.1.3-1-default (openSUSE Tumbleweed), BlueZ 5.82,
>>    PipeWire 1.6.8 / WirePlumber 0.5.15 (HFP native backend, laptop = HF)
>> - Bluetooth: Intel 8265 [8087:0a2b], full-speed, internal (bus 1 root
>>    port 7), fw ibt-12-16
>> - USB headset: C-Media [0d8c:0014], full-speed, mono capture 48 kHz
>> - Dock: Lenovo USB dock (hubs 17ef:3071/17ef:3070, cascade incl.
>>    067b:2586 and 05e3:0610)
>> - HFP counterpart: Android phone (Volla X23) as AG; a call was placed to
>>    a second handset held at my ear, so I judged the far-end quality
>>    directly while speaking
>>
>> SCO detail during mSBC: eSCO, air mode Transparent, 60-byte RX/TX packet
>> length, btusb isoc alt setting 1 (9-byte packets), HCI SCO frames
>> dlen 24. CVSD uses alt setting 2 (17-byte packets).
>>
>> Reproduction (single call, changing only the capture source / port)
>> -------------------------------------------------------------------
>> I kept the same position and speech style throughout and judged the
>> quality on the far-end handset:
>>
>>    uplink capture source                    far-end verdict
>>    1. HS webcam (behind the same dock)      clean
>>    2. FS headset behind dock hub A          severely "robotic"
>>    3. same, headset moved 30 cm away        severely "robotic"
>>                                             (rules out mic proximity/ 
>> level)
>>    4. FS headset on a DIRECT root port      clean
>>    5. FS headset behind dock hub B          severely "robotic" again
>>                                             (immediately reversible)
>>
>> A parallel capture of the same source during phase 5 (recording to a file
>> while the stream also feeds the call) contains audible subtle glitching
>> already at the capture side -- i.e. the corruption exists in the USB
>> capture data before any Bluetooth/mSBC processing. Amplitude analysis
>> shows no zero-runs or full-scale clicks, so the defect consists of small
>> sample-level discontinuities, which the frame-based mSBC codec then
>> amplifies into severe artifacts, while sample-based CVSD mostly masks
>> them.
>>
>> What I ruled out
>> ----------------
>> - Bluetooth host stack: btmon traces covering a clean -> robotic -> clean
>>    cycle show the HCI SCO TX stream is byte-perfect (intact 60-byte mSBC
>>    framing with H2 headers, ~3333 frames/10 s constant) and the write
>>    timing pattern is identical between clean and robotic phases 
>> (bursts of
>>    3x24 B every ~7.5 ms). The RX direction is likewise clean. So
>>    BlueZ/PipeWire/btusb submit correct data on time; the corruption
>>    happens elsewhere.
>> - Audio content/level: same speech, same position (phase 3).
>> - The specific adapter/hub: reproduced behind two different hub chains,
>>    and with a different FS combo headset (Sennheiser) behind a different
>>    (Thunderbolt) dock in another location -- there the mSBC *downlink*
>>    died completely while CVSD kept working.
>> - PipeWire graph effects: an *idle* parallel capture from the FS device
>>    behind the dock (both via PipeWire and via direct ALSA hw:) does NOT
>>    disturb a call whose uplink comes from the HS webcam -- the corruption
>>    only matters when the TT capture stream is the one feeding the call.
>>    Consistent with the corruption being on the TT capture stream itself.
>>
>> Possibly related: "Bluetooth: hci0: corrupted SCO packet" bursts (~14-32
>> messages) at SCO setup time, with both codecs, transient. Earlier this
>> year, on 6.18.8 with the Thunderbolt dock setup, mSBC showed frequent
>> decode errors but audio still flowed; I have not bisected.
>>
>> Questions
>> ---------
>> 1. Is this a known limitation of xHCI TT split-isochronous scheduling
>>     with two concurrent FS isoc streams (one behind a TT, one on a root
>>     port)? EHCI had a software TT scheduler
>>     (CONFIG_USB_EHCI_TT_NEWSCHED); as far as I can tell xHCI relies on
>>     hardware scheduling with no equivalent knob.
>> 2. Which captures would help most? I can provide btmon traces (a 26 MB
>>     clean/robotic cycle), usbmon captures, xhci dynamic debug logs and
>>     audio samples, and I'm happy to test patches.
> 
> both xhci traces, and dynamic debug of a failing case behind a hub,
> and successful case behind a roothub port could reveal something.
> 
> mount -t debugfs none /sys/kernel/debug
> echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
> echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
> echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> < Reproduce issue >
> Send output of dmesg
> Send content of /sys/kernel/debug/tracing/trace
> 
> xhci traces should show all split transaction errors, and ring
> under/overrun events.
> 
> There are a couple patches related to isoc transfer scheduling that
> could be worth testing. They are not directly related to split
> transactions but maybe worth a shot.
> 
> https://lore.kernel.org/linux-usb/20260513143533.52992-1- 
> [email protected]/
> https://lore.kernel.org/linux-usb/20260513143533.52992-2- 
> [email protected]/
> 
> -Mathias