#1152963 linux-image-6.12.115+deb13.1-amd64: no audio on Audient iD4 USB interface (playback never advances)

#1152963#5
Date:
2026-11-03 19:04:20 UTC
From:
To:
Hello,

After updating to linux-image-6.12.115+deb13.1-amd64 (6.12.115-2) on
Debian 13 (trixie), my Audient iD4 USB audio interface (USB ID 2708:0009)
no longer plays sound. With the previous kernel 6.12.113+deb13-amd64
(6.12.113-1) it works perfectly. This looks like a regression in
snd-usb-audio / USB handling between these two versions.

Details with the failing kernel (6.12.115-2):

  *
The card is detected: lsusb and aplay -l list it as card 2, iD4, and
     *
snd_usb_audio is loaded.
  *
Playback never progresses. With
     *
"speaker-test -D plughw:iD4 -c 2 -t wav -l 1" the output hangs on
"Front Left".
  *
While it hangs, /proc/asound/card2/pcm0p/sub0/status shows
     *
state: RUNNING, but hw_ptr stays at 0 and the buffer stays full
(appl_ptr: 24000, avail: 0). hw_params: S32_LE, 4 channels, 48000 Hz.
  *
It happens even with PipeWire and WirePlumber stopped, so it is not a
     *
sound server problem.
  *
Opening a capture stream at the same time (arecord) does not help.
  *
Loading snd_usb_audio with lowlatency=0 or implicit_fb=1 does not help.
  *
/proc/asound/card2/stream0 reports "Implicit Feedback Mode: Yes"
     *
(playback endpoint 0x01 ASYNC, sync endpoint 0x81).
  *
dmesg only shows repeated "cannot get min/max values for control"
     *
messages for the device (usb 1-9.3), and no other errors.
  *
Rebooting into 6.12.113+deb13-amd64 fixes the problem with no other
     *


USB topology (relevant part of lsusb -t). The iD4 is connected through a
4-port high-speed hub, on an Intel xHCI controller:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 009: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 003: Dev 005, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 003: Dev 005, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 003: Dev 005, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 003: Dev 005, If 3, Class=Human Interface Device, Driver=usbhid, 480M
|__ Port 003: Dev 005, If 4, Class=Application Specific Interface, Driver=[none], 480M

Please let me know if I can provide more information or test anything.

Thanks.

#1152963#10
Date:
2026-11-04 00:01:46 UTC
From:
To:
I can report the exact same problem with USB Audio interface Focusrite Scarlett 18i8 3rd Gen (1235:8214), so it could be a generic regression for many USB class compliant audio devices.

Booting linux-image-6.12.115+deb13.1-amd64, all the hardware is detected as it should and there aren't any configuration differences. But there is no sound output at all.

Booting using linux-image-6.12.113+deb13-amd64 again brings everything back to normal.

#1152963#15
Date:
2026-11-04 13:56:32 UTC
From:
To:
Hello,

Some additional information.

A correction to my first report: the iD4 is plugged directly into a
rear USB port of the motherboard, not into an external hub. The 4-port
hub that appears in lsusb -t is the hub built into the ASUS motherboard
(ASMedia ASM1074, 174c:2074; the port shows connect_type "fixed").

Thanks to the second report (Focusrite Scarlett 18i8 3rd Gen, 1235:8214),
this does not look specific to the Audient iD4. Both devices use implicit
feedback for playback, so the regression may affect USB audio devices in
implicit feedback mode in general.

I compared the changelog of linux 6.12.115-2 with 6.12.113-1. The only
change to sound/usb (snd-usb-audio) in between is this one, from 6.12.114:

  ALSA: usb-audio: Prevent excessive number of frames (CVE-2026-23208)

The implicit feedback changes ("Optimize the copy of packet sizes for
implicit fb handling" and "Clamp implicit feedback packet count to URB
capacity") were already in 6.12.113, which works fine. So the
"Prevent excessive number of frames" change is my main suspect. This
matches the symptom: the stream is RUNNING but hw_ptr never advances,
as if no packets were ever submitted to the device.

I have not built a test kernel. I can test a package or a kernel
from another source if you provide one.

Thanks,
Jorge