Re: [REGRESSION] Audient EVO4 hardware volume control now requires quirk

[Christian Ruppert <arc@gmx.li>]

On Tue, Sep 29, 2026 at 04:28:59PM +0200, Takashi Iwai wrote:
> On Tue, 29 Sep 2026 16:24:24 +0200,
> Faaris Ansari wrote:
> > 
> > Thanks Takashi and Sasha,
> > 
> > 
> > > Faaris, please let us know if this (or previous) one actually works
> > > for you.  Once after confirmation, I'll submit the proper patch for
> > > upstream.
> > 
> > I tested your latest patch where you removed the quirk for the iD14
> > alone, and instead set it for all Audient devices.
> > 
> > I can confirm that this has indeed fixed the problem, and I can now
> > correctly control my hardware volume without problems, thank you!

On the surface, this does seem to fix the issue but after looking into it
a bit more in detail, the EVO4 is a bit quirky but its behaviour actually
coherent and expected. I wonder if this should be fixed by simply
disabling error propagation or if it's rather an issue with UCMs. The
situation is as follows:

- The EVO4 presents two PCM devices, each with four channels ("EVO4 " for
  playback and "Mic" for capture).
- In both devices, only the volume of the first two channels can be
  adjusted (Stereo master playback volume for "EVO4 " and two microphone
  gains in "Mic").
- The other two channels of each device are mapped to digital loopback
  (playback) and the digital mixer matrix output (capture) which don't
  have volume controls. Trying to adjust these two is thus invalid and the
  device rightly returns an error.

It is true that the "logical" thing would have been to split everything
into four dual-channel PCM devices, two with adjustable volumes and two
without. For some reason, Audient didn't make that design choice and as
things are the situation is perfectly manageable with UCM and correctly
described in
https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/USB-Audio/Audient/Audient-EVO4-HiFi-0006.conf).

The question is now why the UCM tries to adjust mixer channels which are
clearly not declared as part of the respective "split channel" in that
file. I would argue this is rather a bug in UCM (or possibly an overly
eager "put" function in the generic mixer driver) than in the EVO firmware
or the error propagation. In practice, the error disappears either way but
I suspect that at least part of the motivation behind UCM was to address
exactly this type of issues.

This is rather philosophical and my background on UCM is basically nil so
I would be interested in more educated opinions.

> > > ... or if you have a chance to test Christian's patch set and verify
> > > whether the problem is fixed there, we can avoid other changes:
> > >    https://lore.kernel.org/20260919151840.24371-1-arc@gmx.li
> > I tested Christian's patch alone, without any other changes. The
> > problem still occurred with those patches.
> > 
> > This was also noted by Christian:
> > 
> > > As a matter of fact, I made a similar
> > > observation to yours when testing the patch set on the 'sound' kernel tree
> > > and the (very sporadic) issue did not disappear after applying the
> > > patches.
> > And further discussion below:
> > 
> > https://lore.kernel.org/all/CANBVYRAr8iFGFDgdTcDXuQyXt5M4TddZetsG9o1wbFao03R0yw@mail.gmail.com/
> > 
> > 
> > However, using both patches together (as well as a small patch for
> > alsa-ucm-conf) has made my interface work very well - I'm very happy
> > with these changes :)
> > 
> > 
> > Thank you for your work, Sasha, Takashi, and Christian,
> > 
> > Faaris
> 
> Thanks for clarification.  Then we need a fix like mine in anyway.
> I'm going to submit the proper patch.
> 
> 
> Takashi

-- 
  Christian Ruppert                                             <arc@gmx.li>

This message is digitally signed with GnuPG.
GPG/PGP Key fingerprint = 4492 2196 75F0 EAA0 981E  B661 1476 F17A 975F 587B