[RFC V4 PATCH 00/19] Re: ALSA: mixer_audient: Cache rework and simplifications

[Christian Ruppert <arc@gmx.li>]

Hi Will,

On Wed, Nov 11, 2026 at 08:37:14PM -0600, Will Porter wrote:
> On Tue, Nov 10, 2026 at 09:57:40PM +0100, Christian Ruppert wrote:
> > 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.
> 
> I like the idea. When I read the code for it, I saw a few more places
> where the driver could be simpler. It seemed easier to show them as
> patches than to describe them, so here they are for you to try on the
> EVO4. Please take what you like and drop the rest.

OK, so here's RFC V4 with the cache changes and a few other
improvements inspired by your suggestions. Also contains your follow-up
patch weaved into 13 and 15. See below for details.

Compiles on Alsa master and compiled and tested on 7.3.4.

> > I'll prepare a new patch 10 but won't be able to test before the week-end.
> 
> Patches 3 to 6 need the cache change as a base, so patch 2 is my
> version of it, only so that the rest can be tested. Please replace it
> with yours. Two questions came up when I wrote it:
> 
> - The notify paths clear info->cached unless get_cur_broken is set. A
>   write-only control could not read its value back after that. Patch 2
>   sets get_cur_broken for the write-only controls. Is that a correct
>   use of the field?

I was wondering about the same but originally didn't plan to set it as
it doesn't make much sense without the control and head.id fields. To
settle the question once and for all, I decided to add all three to
patch 10 after all.

> - The interrupt path clears the bit of the channel number in the
>   message, and channel 0 clears all bits. Patch 2 uses the channel
>   index in the element as the bit. Would the channel number of the
>   request fit your EVO4 events better?

I tried to stick to the hardware channel numbers as they are the ones
used in mixer.c as well. Please see patch 10.

> > Do you think it makes sense to refactor FU12 caching as well?
> 
> Yes, I think so: the driver then has one cache. Patch 6 does it.
> 
> The patches:
> 
> 1. Not for merging. It has the changes from your review as one diff,
>    so that patches 2 to 6 apply to the RFC with the enum fix.

OK, didn't touch those in the RFC, please squash them into the
respective patches.

> 2. Use cached and cache_val[] of usb_mixer_elem_info.

This is almost identical to what I had prepared, except for a few
parameter names and indices. Please double-check the new patch 10 to
make sure I didn't miss anything, I can't fully test it on the EVO.
There is also a subtle behavioural change when initializing write-only
cache values. Shouldn't have an impact as it only affects integer and
boolean types but let me know if something comes up in your tests.

> 3. Replace INIT_HW, FORCE_SET and CACHE with an access mode:
>    read-back, cached or write-only. The tables use only these three
>    combinations of the flags. Do you plan to use another combination
>    on the EVO4, for example INIT_HW on a control that can be read? If
>    so, I will drop this patch.

I don't like this, it violates the separation of mechanism from politics
which I hold dear. Also, see the newly added patch 19 for an example why
the flags are useful as they are (turns out ID12 is just such an INIT_HW
control that can be read).

> 4. Fill the cache on the first get or put, not at probe. The probe
>    then sends 12 fewer GET requests on the EVO4 and 56 fewer on the
>    iD14. Is there a reason for the EVO4 to read at probe?

This is a good idea, now (no longer) part of patch 10.

> 5. Use one get and one put for booleans, integers and enums. This
>    changes the code path of the EVO4 controls, which I cannot test.

This is also a good idea, I added patch 18 for this.

> 6. Use the same cache for the FU 12 control.

I added patch 19 with another proposal I came up with when working on
patch 18. Removes all iD14/FU12 specific functions and shortens the code
by another 60ish lines. Please double-check if this makes any sense as I
might have badly misunderstood something. We could even get rid of the
FU12 specific value type if the iD14 accepts -127 * 256 as a volume
setting (the one which is currently skipped and replaced with MUTE). In
this case FU12 would become a normal integer control with a step size of
256.

We might also make some more code more generic if we replace the current
hwchannels with a mask of don't-touch channels. This is not yet included
in the patches because I first wanted to discuss it with you and we
don't have to submit this as part of the current patch set, can be
submitted as a follow-up simplification for a future kernel version.

With above two items, all FU12 specific branches should be gone.

> [...]

I suggest we now proceed as follows:
- Re-check patches 1 through 12, I don't believe they need to be changed
  anymore unless if we discover a bug.
- Weave patch 17 into patches 13 through 16.
- Review patch 18 (I suggest to keep it separate as it is).
- Decide what you would like to do with patch 19 and the two related
  comments after your point 6, either drop or modify patch 16
  accordingly, possibly after rebasing it on top of patch 18.
- Submit the series for final review and testing and subsequent merging.

Do you think this would work?
  Christian

Christian Ruppert (13):
  ALSA: rename mixer_evo to mixer_audient
  ALSA: mixer_audient: explicitly define full control names
  ALSA: mixer_audient: clarify USB control message definition
  ALSA: mixer_audient: Add length check to USB transfer
  ALSA: mixer_audient: make USB control transfer size configurable
  ALSA: mixer_audient: Allow arbitrary boolean control values
  ALSA: mixer_audient: Add integer range checks
  ALSA: mixer_audient: Add control initialization at probe
  ALSA: mixer_audient: Add readback-free parameter set
  ALSA: mixer_audient: add control value caching
  ALSA: mixer_audient: Create matrix programmatically
  ALSA: mixer_audient: Unify snd_audient_*_set/get functions for
    different types
  ALSA: mixer_audient: Refactor FU12 special cases into generic set/get
    functions

Will Porter (6):
  ALSA: mixer_audient: Add a step size to integer controls
  ALSA: mixer_audient: Add enumerated controls
  ALSA: usb-audio: Give the Audient iD14 MkI its own mixer map
  ALSA: mixer_audient: Add Audient iD14 MkI controls
  ALSA: mixer_audient: Replace the Audient iD14 MkI FU 12 control
  ALSA: mixer_audient: Fold in the review changes to patches 12-16

 MAINTAINERS               |    7 +-
 sound/usb/Makefile        |    2 +-
 sound/usb/mixer_audient.c | 1118 +++++++++++++++++++++++++++++++++++++
 sound/usb/mixer_audient.h |   13 +
 sound/usb/mixer_evo.c     |  526 -----------------
 sound/usb/mixer_evo.h     |   12 -
 sound/usb/mixer_maps.c    |   10 +-
 sound/usb/mixer_quirks.c  |    5 +-
 8 files changed, 1148 insertions(+), 545 deletions(-)
 create mode 100644 sound/usb/mixer_audient.c
 create mode 100644 sound/usb/mixer_audient.h
 delete mode 100644 sound/usb/mixer_evo.c
 delete mode 100644 sound/usb/mixer_evo.h

-- 
2.56.1