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

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:
> >> [email protected]
> >>                      Signed-off-by: Gordon Chen <[email protected]>
> >> 
> >>                  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