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

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

```

-- 
Best Regards,
Mark Shi