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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.