Re: [PATCH 0/5] ALSA: usb-audio: Audient iD14 MkI vendor controls

[Will Porter]

Hi Christian,

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.

> 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.

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.

> - 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.

> - 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?

> - We definitely need a new snd_evo_type entry and get/set functions
>   for enums, up to you to define those in the most suitable manner
>   for the id14.

OK, I'll write the enum type with the iD14 tables.

> Sure, error management is always good to have. [...] Also, for the
> controls I checked, the EVO cleanly rejects out-of-range writes but
> if the id14 doesn't we should add those checks as well.

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.

> I would definitely prefer to list both of us as maintainers.

Okay, let's do that.

> I suggest I submit an RFC with the generic part that you can apply
> locally to work against (and potentially adjust) before you submit
> everything in a final series which, if everything goes well, I only
> need to retest and tag.

That works for me. I'll carry your rename and generic patches in the
final series, with your authorship and Signed-off-by kept and mine
added, followed by the iD14 patches. Are your four fixes still going in
separately first? And could you include the base commit in the RFC?

Thanks,
Will