From: Takashi Iwai <tiwai@suse.de>
To: JJ Macalinao <jj@macalinao.org>
Cc: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
linux-sound@vger.kernel.org, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS
Date: Sat, 08 Aug 2026 17:14:22 +0200 [thread overview]
Message-ID: <87se4oabld.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260808070902.835360-1-jj@macalinao.org>
On Sat, 08 Aug 2026 09:09:02 +0200,
JJ Macalinao wrote:
>
> set_sample_rate_v2v3() returns early when the clock already reports the
> requested rate:
>
> prev_rate = get_sample_rate_v2v3(chip, fmt->iface,
> fmt->altsetting, clock);
> if (prev_rate == rate)
> goto validation;
>
> A device advertising exactly one sample rate always takes this branch, so
> it never receives a SET_CUR for CS_SAM_FREQ_CONTROL at all.
>
> The Mackie DLZ Creator XS (0a73:003a, 14 in / 4 out, 48 kHz only) requires
> that write. Without it the device drops off the USB bus roughly 0.2-1.8 s
> into any stream, clearing its port CONNECTION bit; captured audio is
> byte-correct until the instant it vanishes.
>
> USBPcap traces of a cold-booted device on Windows show SET_CUR 48000 issued
> unconditionally on every stream start, followed by clean streaming. The
> device is otherwise driven with plain class-compliant UAC2 - it also works
> on iOS, which cannot load a vendor driver - so no vendor-specific
> initialisation is involved.
>
> The device is self-powered, so the resulting state survives a USB replug:
> initialising it on any host that issues the write leaves it working on
> Linux until it is power-cycled, which made the failure look intermittent.
>
> Add a quirk flag rather than dropping the early exit, since the opposite
> requirement also exists in-tree: QUIRK_FLAG_FIXED_RATE suppresses rate
> setting for single-rate devices (JBL Quantum610/810). The two behaviours
> are device-dependent and cannot both be the default.
>
> A/B on identically cold-booted hardware, same kernel, same port, repeated
> twice:
>
> without the flag device dropped after 5-6 s, then again after 3-4 s
> with the flag 20 s playback followed by 20 s of 14-channel capture,
> 960000 frames, zero re-enumerations
>
> This change was developed with an AI coding assistant. The assistant did
> the trace analysis that located the bug and wrote the patch and this
> changelog; the hardware testing, the cold-boot cycles and the decision to
> submit were the author's. Several earlier hypotheses it proposed - URB
> queue depth, isochronous packet under-allocation, endpoint start ordering -
> were disproven by measurement before this one.
>
> The bug was located with usbmon on Linux and USBPcap on Windows, by
> diffing an enumeration capture of a cold-booted device on each host.
> Verified on physical hardware by the A/B above.
>
> Assisted-by: Claude-Code:claude-opus-5
> Signed-off-by: JJ Macalinao <jj@macalinao.org>
> ---
> sound/usb/clock.c | 3 ++-
> sound/usb/quirks.c | 3 +++
> sound/usb/usbaudio.h | 6 ++++++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/sound/usb/clock.c b/sound/usb/clock.c
> index 2e0c18e352..647bf55b1b 100644
> --- a/sound/usb/clock.c
> +++ b/sound/usb/clock.c
> @@ -626,7 +626,8 @@ static int set_sample_rate_v2v3(struct snd_usb_audio *chip,
> }
>
> prev_rate = get_sample_rate_v2v3(chip, fmt->iface, fmt->altsetting, clock);
> - if (prev_rate == rate)
> + if (prev_rate == rate &&
> + !(chip->quirk_flags & QUIRK_FLAG_ALWAYS_SET_RATE))
> goto validation;
With QUIRK_FLAG_ALWAYS_SET_RATE, calling get_sample_rate_v2v3() is
rather useless, and we can skip it? e.g.
if (!(chip->quirk_flags & QUIRK_FLAG_ALWAYS_SET_RATE)) {
prev_rate = get_sample_rate_v2v3(chip, fmt->iface, fmt->altsetting, clock);
if (prev_rate == rate)
goto validation;
}
thanks,
Takashi
next prev parent reply other threads:[~2026-08-08 15:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 7:09 [PATCH] ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS JJ Macalinao
2026-08-08 15:14 ` Takashi Iwai [this message]
2026-08-08 16:20 ` JJ Macalinao
2026-08-08 17:27 ` [PATCH v2] " JJ Macalinao
2026-08-09 10:30 ` 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=87se4oabld.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=jj@macalinao.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/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