Re: [PATCH] ALSA: usb-audio: add Pioneer DJ DDJ-SZ support

[Geraldo Nascimento]

Hi Hanh,

On Fri, Sep 4, 2026 at 3:20 PM Hanh Kieu <hhkieu@xxxxxxxxx> wrote:
>
> Geraldo Nascimento wrote:
> > Are you sure is_pioneer_implicit_fb() isn't returning false and you're
> > picking up on a generic sync ep instead?
> >
> > You should double-check that function is returning true or false because
> > it will return false when USB_ENDPOINT_USAGE_IMPLICIT_FB isn't
> > set on bmAttributes of a Isochronous IN EP.
>
> Good catch, thanks -- I checked against the real device rather than
> assuming.

Thanks.

>
> lsusb -v on the DDJ-SZ shows both endpoints (0x01 OUT, 0x82 IN) as
> Isochronous / Asynchronous with Usage Type = Data (bmAttributes = 0x05).
> is_pioneer_implicit_fb() accepts the capture endpoint's usage being
> either USB_ENDPOINT_USAGE_DATA or USB_ENDPOINT_USAGE_IMPLICIT_FB, not
> IMPLICIT_FB exclusively, so Data usage does pass that check.

Thanks for this report.

The code snippet in question is in the body of is_pioneer_implicit_fb()
in sound/usb/implicit.c:

epd = get_endpoint(alts, 1);
if (!usb_endpoint_is_isoc_in(epd) ||
   (epd->bmAttributes & USB_ENDPOINT_SYNCTYPE) != USB_ENDPOINT_SYNC_ASYNC ||
   ((epd->bmAttributes & USB_ENDPOINT_USAGE_MASK) !=
    USB_ENDPOINT_USAGE_DATA &&
    (epd->bmAttributes & USB_ENDPOINT_USAGE_MASK) !=
    USB_ENDPOINT_USAGE_IMPLICIT_FB))
return false;

In my opinion the logical AND at the end of the if condition is short-circuited
by doing that inequality comparison between USB_ENDPOINT_USAGE_DATA
and the result of the bitwise AND between bmAttributes and
USB_ENDPOINT_USAGE_MASK, because 0x05 & 0x30 == 0x00.

When that first condition evaluates to false C never bothers to check the other
half of the logical AND, for logical and practical reasons.

What I'm not sure of is that's the kind of check we want for Pioneer implicit fb
matching... Takashi will have to be the judge here, but I think it is
not intended
behavior that this function picks up implicit fb without
USB_ENDPOINT_USAGE_IMPLICIT_FB being set. The fact is does so probably
means that code in implicit.c needs a bit of improvement.


>
> I also traced snd_usb_parse_implicit_fb_quirk()'s dispatch order for
> this device to make sure nothing generic intercepts first: no fixed or
> capture quirk-table entry matches 08e4:0191, it isn't UAC2
> (bInterfaceClass is vendor-spec, not USB_CLASS_AUDIO), and it isn't the
> Roland vendor ID. So is_pioneer_implicit_fb() is the function actually
> being reached and returning true for this device, not a coincidental
> generic fallback.

Again, thanks for your due dilligence, and for all your work, it's looking
good.

Thanks,
Geraldo Nascimento