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

[Takashi Iwai]

On Mon, 26 Oct 2026 22:44:50 +0100,
Will Porter wrote:
> 
> Hi Christian,
> 
> On Mon, Oct 26, 2026 at 07:36:24PM +0100, Christian Ruppert wrote:
> > I took a look at this question and it seems like we can share the majority
> > of code in the EVO driver by complementing it with the following features:
> > - variable width read/write
> > - caching of write-only values
> > - enum data type
> 
> Thanks for looking into this so closely, and for the fixes. I like
> the idea of one driver, and I'd like to find out whether the iD line fits.
> 
> Your TLV in patch 4/4 is the same one I use for the iD14 matrix: same
> unit 0x3C, s16 in 1/256 dB, -128 to +6 dB. That made me wonder whether
> the iD14 matrix could use your MIXER type almost as it is. Its channel
> number is input * 4 + output, so Main L/R and Cue L/R of each input
> are adjacent, like your stereo pairs. Could we expose it as 28
> controls with two values each, rather than my 56 single-value ones?
> An input's level and pan in a mix set its L and R values together,
> so a pair seems a natural fit. Does that look right to you?
> 
> > The only part which seems more problematic is probably FU12 which looks
> > like it requires some custom logic and would still need actual code.
> 
> Agreed. I'd keep FU 12 as its own code.
> 
> A few questions about the rest:
> 
> 1. Read before write. As I understand it, the put handlers in
>    mixer_evo.c read the value first to see if it changed. On the iD14,
>    GET stalls for mic boost, input polarity, optical mode and the iD
>    key function, so a put that reads first would fail there. Talkback
>    source always reads 0, so a read would hide real changes. Could
>    these write-only controls skip GET in both get and put, with get
>    returning the cached value? And could every put still send the
>    value, even when it matches the cache, so that "alsactl restore"
>    reaches a device that was reset?
> 
> 2. The cache. My driver writes a known value at probe (off or none,
>    and for optical mode its measured power-on mode, S/PDIF) and
>    updates the cache only after a full-length write. If the probe
>    write fails, an enum reads "Unknown" and a switch reads off. Would
>    that approach work for you?
> 
> 3. Control entries. The iD14 table uses 16 unit/selector pairs and
>    explicit control names, such as "Main Out L Source Playback Enum".
>    It also needs volumes in 1 dB steps (0..128, stored as s16
>    1/256 dB), a boost switch that writes 0x0a00 for on, and enums
>    that map items to device values, plus an "Other" item that only
>    get reports, for values outside the list. Would it make sense to
>    move the unit, selector and an optional full name into each control
>    entry, and add the new value formats (1 dB volumes, boost, enum)
>    as ctypes? Or would you structure it differently?
> 
> 4. Checks. My helper returns -EIO on a short read or write, before
>    it decodes a value or updates the cache. My matrix put also rejects
>    values outside -128..+6 dB, and get clamps what it reads back.
>    Could the shared code keep these checks?
> 
> I don't have a firm view yet on which way is better. If the iD14
> fits the table without many special cases, one driver seems clearly
> worth it. If it needs a lot of per-device branches, two smaller files
> might be easier to read and review. What do you think, now that you
> have seen what the iD14 needs?
> 
> If we do combine them, the order I imagined is: your four fixes first,
> then the rename to Audient, then the generic changes, then the iD14
> tables on top as v2 of my series.
> 
> In that case, would you prefer to do the rename and the generic part
> yourself? The rename would also touch MAINTAINERS; how would you like
> to handle review of the iD14 parts? I can write the iD14 parts and
> test them on my MkI. I don't have an EVO 4, so would you be able to
> test that side? And which base should I work against, sound for-next
> once your fixes are in? I'm also not sure how a combined change
> should reach Takashi: as one series, or as two with a stated
> dependency.

Well, it's all up to you guys :)
Just arrange between Christian and you, then resubmit, either v2 or
additional patches.  I'll be traveling from tomorrow and can't react
for a few days, in anyway.


thanks,

Takashi