Re: [RFC PATCH 13/16] ALSA: mixer_audient: Add enumerated controls

[Christian Ruppert <arc@gmx.li>]

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]

Hi Will,

On Mon, Nov 09, 2026 at 08:13:02PM -0600, Will Porter wrote:
> [...]
> > - Not sure if this is relevant for the iD14 but we might want to
> >   apply something like DIFF 2 to make update events work on the
> >   replaced controls 11 and possibly 60 [...]
> 
> I left DIFF 2 out of my patches. I have no objection to it, but I
> cannot test it. The audio control interface of the iD14 MkI has no
> interrupt endpoint (bNumEndpoints is 0), so
> snd_usb_mixer_status_create() returns before it creates the URB. The
> device sends no status interrupts, and a knob change shows only by a
> read. On the iD14 the diff only moves the table-created controls from
> id 0 to their unit in id_elems and in the usbmixer proc file.
> 
> Two things in sound/usb/mixer.c may matter for your EVO4 events:
> 
> - snd_usb_mixer_interrupt_v2() skips an element when the unit has more
>   than one element and info->control differs from the control selector
>   in the message. Our elements leave control at 0. Would the event
>   reach them?
> - The notify paths clear info->cached of the generic mixer, not the
>   mixer_audient cache. Would a cached control report its old value
>   after the event?
> 
> Could you carry DIFF 2 with your EVO4 event change?

OK, thanks for the hints, I'll keep them in mind when I start working on
this. I haven't tested the diff either, for the moment it was only a
sketch so it's most probably incomplete. This is actually only required
for the EVO if I decide to replace generic controls - which I might
eventually to keep the philosophy of the driver consistent:
Until now I tried not to touch what was working, even if it's quirky but
as you cleaned up comparable controls for the iD I might just as well do
so for the EVO, too. A higher priority will be to figure out if and how I
can get events for controls not supported by the generic driver, though,
but that will require a few hours on a rainy day...

> [...]
> With these changes each of the five patches builds with W=1 without
> warnings, and checkpatch --strict reports nothing new.
> On the iD14 (stable 7.2.15) the read and write checks of the controls
> pass with the new version.
> 
> For the next version: unless you would like another RFC round, I
> would send it as a normal series, on top of your four mixer_evo fixes
> as before. Does that work for you?

Actually... I was just about to propose the same but when looking at the
code in mixer.c you refer to above (interrupts and cache invalidation) I
realized that usb_mixer_elem_info already contains an integer array for
caching we could use instead of our manually allocated cache. I suspect we
should rework patch 10 accordingly. The positive side-effect of this would
be that info->cached management in the standard notify path would work
should we decide to use it one day.

I'll prepare a new patch 10 but won't be able to test before the week-end.
I'll send a new RFC after that. Do you think it makes sense to refactor
FU12 caching as well?

Cheers,
  Christian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]