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

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/[email protected]/
https://lore.kernel.org/linux-usb/[email protected]/

-Mathias