From: Takashi Iwai <tiwai@suse.de>
To: Mark Shi <liaronce@hotmail.com>
Cc: Takashi Iwai <tiwai@suse.de>,
Gordon Chen <chengordon326@gmail.com>,
linux-sound@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8
Date: Tue, 28 Jul 2026 18:24:34 +0200 [thread overview]
Message-ID: <875x1z6q0t.wl-tiwai@suse.de> (raw)
In-Reply-To: <OS3PR01MB8827BF7068BF30726C2C8A1BDECB2@OS3PR01MB8827.jpnprd01.prod.outlook.com>
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@vger.kernel.org
> >>> Signed-off-by: Gordon Chen <chengordon326@gmail.com>
> >>>
> >> 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.
>
>
> Thanks,
>
> Mark Shi
>
> ---
> sound/usb/endpoint.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> index 24cd7692bd01..6fbcb117555c 100644
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -1780,16 +1780,8 @@ static void snd_usb_handle_sync_urb(struct
> snd_usb_endpoint *ep,
> /*
> * skip empty packets. At least M-Audio's Fast Track Ultra stops
> * streaming once it received a 0-byte OUT URB
> - *
> - * However, on devices where bytes==0 means every sync-source
> - * packet errored (e.g. Behringer Flow 8 returning -EXDEV bursts
> - * for entire capture URBs), an unconditional return starves the
> - * IFB-fed OUT ring permanently. Such devices set
> - * QUIRK_FLAG_IFB_SILENCE_ON_EMPTY to fall through and enqueue a
> - * packet_info with size 0 packets, so playback emits silence
> - * and the OUT ring keeps moving.
> */
> - if (bytes == 0 && !(ep->chip->quirk_flags &
> QUIRK_FLAG_IFB_SILENCE_ON_EMPTY))
> + if (bytes == 0)
> return;
>
> spin_lock_irqsave(&ep->lock, flags);
Could you put a debug print what value does ep->chip->quirk_flags
have on your device?
thanks,
Takashi
next prev parent reply other threads:[~2026-07-28 16:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 7:29 Gordon Chen
2026-05-26 14:28 ` Takashi Iwai
2026-07-28 14:27 ` Mark Shi
2026-07-28 15:02 ` Takashi Iwai
2026-07-28 15:46 ` Mark Shi
2026-07-28 16:24 ` Takashi Iwai [this message]
[not found] ` <OS3PR01MB88275E7D7BCF41FE0689E701DECA2@OS3PR01MB8827.jpnprd01.prod.outlook.com>
2026-07-29 14:44 ` Takashi Iwai
2026-07-30 12:33 ` Mark Shi
2026-07-30 13:13 ` Takashi Iwai
2026-07-30 15:40 ` Mark Shi
2026-07-30 16:03 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875x1z6q0t.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=chengordon326@gmail.com \
--cc=liaronce@hotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®