Re: [PATCH] ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8

[Takashi Iwai]

On Thu, 30 Jul 2026 17:40:11 +0200,
Mark Shi wrote:
> 
> Hi Takashi,
> 
> 在 2026/7/30 21:13, Takashi Iwai 写道:
> > On Thu, 30 Jul 2026 14:33:44 +0200,
> > Mark Shi wrote:
> >> Hi Takashi,
> >> 
> >>> On Wed, 29 Jul 2026 16:28:23 +0200,
> >>> Mark Shi wrote:
> >>>> Hi Takashi,
> >>>> 
> >>>>       On Tue, 28 Jul 2026 17:46:05 +0200,
> >>>>       Mark Shi wrote:
> >>>>                Hi Takashi,
> >>>>                    在 2026/7/28 23:02, Takashi Iwai 写道:
> >>>>                        On Tue, 28 Jul 2026 16:27:35 +0200,
> >>>>               Mark Shi wrote:
> >>>>                                Hi Gordon,
> >>>>                                    在 2026/5/26 15:29, Gordon Chen
> >>>> 写道:
> >>>>                                        The Behringer Flow 8
> >>>> (1397:050c) is an 8-channel USB mixer that
> >>>>                       declares OUT EP 0x01 with implicit feedback from capture EP 0x81 via
> >>>>                       its UAC2 endpoint companion descriptor. After 5-35 minutes of
> >>>>                       continuous playback, the device occasionally returns a capture URB in
> >>>>                       which every iso_frame_desc has a non-zero status (-EXDEV bursts,
> >>>>                       visible as rate-limited "frame N active: -18" lines in dmesg from
> >>>>                       pcm.c).
> >>>>                                            In that case
> >>>> snd_usb_handle_sync_urb() at endpoint.c counts bytes==0
> >>>>                       and falls into the early "skip empty packets" return originally added
> >>>>                       for M-Audio Fast Track Ultra. As a result the playback EP loses its
> >>>>                       sole IFB-driven feeder and the OUT ring starves permanently: hw_ptr
> >>>>                       stops advancing while substream state remains RUNNING. Only USB
> >>>>                       re-enumeration recovers.
> >>>>                                            Three independent ftrace
> >>>> captures (taken at the moment of stall via a
> >>>>                       userspace watchdog) consistently show:
> >>>>                                                - 60-70 capture URB
> >>>> completions in the 70ms window before the marker
> >>>>                           - 0 retire_playback_urb / queue_pending_output_urbs /
> >>>>                             snd_usb_endpoint_implicit_feedback_sink calls
> >>>>                           - every usb_submit_urb in the window comes from
> >>>>                             snd_complete_urb+0x64e (capture self-resubmit), none from the
> >>>>                             queue_pending_output_urbs path
> >>>>                                            Add a new opt-in quirk
> >>>> QUIRK_FLAG_IFB_SILENCE_ON_EMPTY: when set, the
> >>>>                       early return is skipped and we fall through to enqueue a packet_info
> >>>>                       whose packet_size[i] are all 0 (the existing loop already maps
> >>>>                       status!=0 packets to size 0). prepare_outbound_urb then emits a
> >>>>                       silence packet, the OUT ring keeps moving, and the device rides
> >>>>                       through the glitch.
> >>>>                                            The default behaviour
> >>>> (early return) is preserved for all existing
> >>>>                       devices including M-Audio Fast Track Ultra. Only Flow 8 opts in here.
> >>>>                                            Cc:
> >>>> stable@xxxxxxxxxxxxxxx
> >>>>                       Signed-off-by: Gordon Chen <chengordon326@xxxxxxxxx>
> >>>> 
> >>>>                   Device: Mechrevo WUJIE14Pro A-7BC4U
> >>>>                   CPU: AMD Ryzen 7 7840HS (Codename "Phoenix")
> >>>>                   Firmware Version: T140_PHX_V20
> >>>>                   Firmware Release Date: 2024.1.8
> >>>>                   Kernel version: 7.1.4
> >>>>                                    In Linux kernel 7.1.4, I found
> >>>> that my laptop couldn't wake up from S3
> >>>>                   suspend; I had to hold down the power button to force a shutdown and
> >>>>                   then restart it.
> >>>>                                    Using `git bisect`, I discovered
> >>>> that if I revert this patch, the
> >>>>                   laptop resumes from S3 normally.
> >>>>                                Do you have this USB-audio device
> >>>> (Behringer Flow 8 with USB ID
> >>>>               1397:050c)?  The commit must be harmless unless you have this device.
> >>>>               That is, if you don't have this device, it's likely a false-positive
> >>>>               bisection result.
> >>>> 
> >>>>               thanks,
> >>>>                            Takashi
> >>>>                        I don't have that device, but I partially
> >>>> reverted the code in that
> >>>>           section, and it went back to normal.
> >>>>                Hmm, that's odd.
> >>>>            Could you put a debug print what value does
> >>>> ep->chip->quirk_flags
> >>>>       have on your device?
> >>>> 
> >>>>       thanks,
> >>>>            Takashi
> >>>>       I added `usb_audio_info`, compiled and booted, but `dmesg |
> >>>> grep "quirk_flags"
> >>>> ` returned no output.
> >>> Then something wrong in your test :)
> >>> 
> >>> Put another debug print at another place like the probe function, in
> >>> order to verify whether the patched driver is really loaded, too.
> >>> And, make sure that you're running the exactly patched kernel.
> >>> 
> >>> 
> >>> Takashi
> >> 
> >> I used the `printk` function to retrieve the `quirk_flags` for the
> >> current function. Here is the output:
> >> 
> >> ```
> >> 
> >> [   23.225719] snd-usb-audio: quirk_flags = 0x100800
> >> 
> > And what about ep->chip->quirk_flags at the place in question?  Does
> > it show the very same value?
> > 
> > The value 0x100800 means that your device has the quirk bit 11
> > (QUIRK_TYPE_IFACE_DELAY) and bit 20 (QUIRK_TYPE_FORCE_IFACE_RESET),
> > and they have nothing to do with the commit you're testing.
> > 
> > 
> > thanks,
> > Takashi
> 
> I modified the output and added two log points for this purpose, and output:
> 
> ```
> 
> [   23.355939] snd-usb-audio:snd_usb_endpoint_start() quirk_flags = 0x100800
> [   23.437401] snd-usb-audio:snd_usb_endpoint_start() quirk_flags = 0x100800
> [   67.813139] snd-usb-audio:snd_usb_endpoint_start() quirk_flags = 0x100800
> 
> ```
> 
> Regardless of whether I added a log point,
> `snd_usb_endpoint_implicit_feedback_sink()` did not produce any
> output.
> 
> However, without the partial code rollback, during the 7.1.3–7.1.4
> period, I could only restore normal operation by disabling PCIe power
> management using the "pcie_port_pm=off" kernel parameter (from
> "amd_s2idle.py" script's report).
> 
> Unfortunately for me, the platform returned to normal in version 7.1.5
> (even though I hadn't applied any patches) (T_T). This makes it
> impossible for me to determine which side is at fault.

Well, that must be a false-positive, as you couldn't get the debug
print at the patch actually touching.

Let us know if you can reproduce the issue reliably and it still
points to this commit.


thanks,

Takashi