[RFC PATCH 00/11] Re: ALSA: usb-audio: Audient iD14 MkI vendor controls

[Christian Ruppert <arc@gmx.li>]

Hi Will,

As discussed here an RFC to prepare iD14 support. It goes on top of the
previous patch set (minor fixes and tlv addition) which I hope can still
make it into 7.4.

The driver was restructured as agreed, with one (short) patch per item to
make the changes as understandable as possible. Up to you to squash them
into fewer ones before submitting everything in order to keep the final
patch series short.

The patches were generated for sound/master commit 603a4df9e6ae60a26adb335f
and tested with linux-7.3.1. In both cases, the "minor fixes and tlv
addition" patch series was applied first. Note that I could not fully test
everything using the EVO4 hardware, some of the newly possible
configurations are only usable with the iD14.

See below for a few more comments about the technical details.

  Christian

On Tue, Oct 27, 2026 at 09:36:23PM -0500, Will Porter wrote:
> On Wed, Oct 28, 2026 at 12:21:51AM +0100, Christian Ruppert wrote:
> > BTW: the mixer matrix seems to be identical also for the EVO8 so
> > chances are it's the same for most audient devices and we could
> > simply use a width and height parameter to generate it in a loop.
> 
> That sounds good to me. On the iD14 it would be 14 inputs by 4
> outputs.

OK, defined as a list of names, see patch 11.

> > My view of the WO implementation would be to add three flags: cache,
> > init and force_write:
> 
> These look right to me. As per-control flags, you could set init on the
> EVO matrix, and for the iD14 entries, could we set it only on the
> write-only controls? The matrix, routing and readable monitor controls
> keep their values across a replug on mains power, so I'd leave those
> untouched at probe. Would each entry also carry its init value? On the
> iD14 most start at off or the first item, but optical mode starts at
> S/PDIF.

Actually, the matrix settings also seem to survive a reboot on the EVO (as
long as the device remains powered) so finally I decided not to initialize
at enumeration either to make the behaviour consistent with the iD14.

Init values are defined in the control type and apply to both the hardware
(if the INIT_HW flag is set) and the cache (e.g. if the FORCE_SET flag is
set without INIT_HW).

> I'd keep force_write on the cached write-only controls, as a precaution
> against a reset that leaves the card registered. I haven't seen that
> on the iD14: the resets I've seen re-enumerate it and run probe again.
> For the readable controls, skipping an unchanged write seems fine to me.

OK, the flags should be rather orthogonal. I couldn't test all combinations
with the EVO, though, so don't hesitate to fix potential issues you might
discover.

> > - The intent of the control types was to associate unit/selector
> >   pairs with data types. I would add a new ctype for each
> >   unit/selector pair [...]
> > - I don't have a preference between explicit control names and the
> >   basename/suffix system the EVO driver currently uses. If you prefer
> >   we can simply replace the basename with a full name and remove the
> >   flags field in the controls.
> 
> Yes, full names would make the iD14 table easier to check. And
> one ctype per unit/selector pair is fine with me.

ok, see patch 2 for the names and patch 3 to make the unit/selector pairs
more explicit.

> > - The boost switch writing 0x0 for 0dB gain and 0x0a00 for 10dB gain
> >   looks suspiciously like a volume control between 0dB and 10dB *
> >   256steps/dB. Does this control only accept these two values or can
> >   we simply implement it as a standard volume type controlling a mic
> >   pre-amp?
> 
> Your guess was correct! The device answers no RANGE request for it, so
> I tried intermediate values with a loopback cable: 0x0100, 0x0280 and
> 0x0500 gave +1, +2.5 and +5 dB on both mic inputs, each tested
> successfully within 0.01 dB of nominal. I didn't test outside 0..+10 dB
> though.
> 
> Even so, I'd like to keep it as a switch in this series, because the
> iD14's documentation describes a fixed +10 dB boost. Your max-for-true,
> min-for-false boolean would fit that, with 0 and 0x0a00. A 0..10 dB
> volume could follow as its own patch if people want it later. Does that
> sound reasonable?

OK, with the current implementation both should be possible with a simple
table change.

> [...]
> I haven't tested whether the iD14 rejects them. Could the generic put
> handlers reject values outside each control's writable ALSA range with
> -EINVAL, before converting them to device values? That would cover
> both devices.

OK, see patch 7.

> [...]

Christian Ruppert (11):
  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

 MAINTAINERS               |   7 +-
 sound/usb/Makefile        |   2 +-
 sound/usb/mixer_audient.c | 633 ++++++++++++++++++++++++++++++++++++++
 sound/usb/mixer_audient.h |  12 +
 sound/usb/mixer_evo.c     | 526 -------------------------------
 sound/usb/mixer_evo.h     |  12 -
 sound/usb/mixer_quirks.c  |   4 +-
 7 files changed, 652 insertions(+), 544 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.0