Re: [PATCH] ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS

JJ Macalinao <[email protected]>
Newsgroups gmane.linux.sound,gmane.linux.alsa.devel,gmane.linux.kernel
Message-ID <[email protected]>
On 8/8/26 23:14, Takashi Iwai wrote:
> 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 <[email protected]>
>> ---
>>  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;
>         }

Makes sense, just need to make sure prev_rate is initialized since it's
used in several places down the line. Will retest and update with v2.
Thank you.

JJ
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.