Re: [PATCH 0/3] Add Audient EVO4 support

[Faaris Ansari]

> I'm afraid this is not going to be the case. The patch set doesn't change
> anything with the pre-existing controls except for renaming the 'EVO4 '
> master volume mixer to 'Master'. 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.

> Unluckily, I didn't have time to investigate and as it seemed independent
> from this patch set and was never observed on my (vanilla) 6.18.x
> day-to-day setup, even with very recent kernels, I forgot about it. I
> suspect this might be a regression in the sound-USB core modules or
> possibly the the alsa core.

I was able to find a work around to this specific issue, adding this
below line in modprobe.d made the hardware volume start working
correctly again.
options snd_usb_audio quirk_flags=2708:0006:ignore_ctl_error
I've reported this regression separately here:
https://lore.kernel.org/regressions/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@xxxxxxxxxxxxxx/

I also was able to test your patches alongside this workaround. All of
the system controls I was expecting were in fact available within
`alsamixer`, including phantom power, mic gain, etc.
Both mic inputs still seem to be reported as stereo even though
they're mono - I think the other channel is for loopback or something?
I'm not entirely sure if this is something the patches are supposed to
solve.

> The patch set doesn't change
> anything with the pre-existing controls except for renaming the 'EVO4 '

On the note of the UCM config, I had to patch it due to the above or
else PipeWire wasn't able to directly manage the hardware volume knob.
Adding the PlaybackSwitch part also allowed the hardware mute to be
used by PipeWire.

46c46,47
< PlaybackVolume "EVO4 "
---
> PlaybackVolume "Master Playback Volume"
> PlaybackSwitch "Master Playback Switch"

One problem I had with this patchset is the settings I have don't seem
to save with UCM / PipeWire. When powering off the interface and
powering it back on again all settings are reset except for the Master
Playback Volume. After a small discussion on the PipeWire matrix
server I was told that these settings should live in the UCM config
too which I'm assuming they do not currently.
Muting the microphone in pwvucontrol also didn't seem to use the
hardware mic mute. Probably need to add `CaptureSwitch` for the
microphone in UCM too.

However, the current state is by far better than how the interface is
being handled by default - thanks so much for your work on this!

Faaris



On Sun, 27 Sept 2026 at 18:12, Christian Ruppert <arc@xxxxxx> wrote:
>
> On Fri, Sep 25, 2026 at 11:18:33AM +0100, Faaris Ansari wrote:
> > Thanks for your work on this - there is currently a regression on the latest
> > kernel versions (7.2 onwards, as well as LTS kernels 6.12 and 6.18). Trying
> > to set the volume in software like wpctl, or pwvucontrol causes the software
> > volume to be pulled down with it - I think it's something to do with "sticky
> > mixers", not completely sure.
> >
> > I worked through troubleshooting it here as I originally thought it was a
> > wireplumber issue:
> > https://gitlab.freedesktop.org/pipewire/wireplumber/-/work_items/1022
> >
> > This patch should hopefully solve that,
>
> I'm afraid this is not going to be the case. The patch set doesn't change
> anything with the pre-existing controls except for renaming the 'EVO4 '
> master volume mixer to 'Master'. 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.
>
> Unluckily, I didn't have time to investigate and as it seemed independent
> from this patch set and was never observed on my (vanilla) 6.18.x
> day-to-day setup, even with very recent kernels, I forgot about it. I
> suspect this might be a regression in the sound-USB core modules or
> possibly the the alsa core.
>
> > and avoid the usage of external
> > kernel modules like https://github.com/vanzaho/audient-evo-py (which you've
> > based your work from)
>
> This one should be solved with the patch set.
>
> > I'm not exactly sure how the process with kernel stuff works, but
> > considering a regression on current mainline as well as LTS branches for
> > this device - is there some chance of fast tracking the merge of these
> > patches?
>
> The best way of supporting this (even if it only solves half of your
> concerns) is probably to test it and reply with a Tested-by: tag to the
> patches.