USB Microphone control shown as a Playback control in tools using alsa-lib

[karlrelton]

I have a 'Clip-on USB microphone UM02' which functions with Alsa just fine,
except for one of its controls: 'Auto Gain Control'.

This control is shown by alsa-mixer on the playback controls 'tab', when one
would logically expect it to be on the capture controls (or perhaps
just show up if the user selects 'ALL').

On a bit of investigation, amixer lists it as follows:
Simple mixer control 'Auto Gain Control',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]

This USB sound device is only a microphone - it has no playback
capabilities. So any controls should either be 'capture' or perhaps
be seen as generic (i.e. playback/capture agnostic) for the device.

The fact that alsa libraries make this control appear to be playback
not only affects user interfaces like alsamixer, but also throws
other tools like pulseaudio/pipewire (with their 'alsa-card-profile' logic).

alsa-info output attached.
alsa_karl1.txt

[karlrelton]

Investigation of code in alsa-lib suggests to me that the issue might stem from the logic in function base_len() in mixer/simple_none.c

That logic compares the name of the control element ("Auto Gain Control") against a set of hard-wired suffixes. None of the possibilities match, so the 'type' is set to CTL_SINGLE.

In function simple_update the logic for a CTL_SINGLE of ctype ..._BOOLEAN plays out as follows for the 'caps':

• Given caps SM_CAP_GSWITCH
• Then SM_CAP_PSWITCH_JOIN is or-ed in
• Then SM_CAP_CSWITCH_JOIN is or-ed in
• Then (in /* exceptions */ section) SM_CAP_GSWITCH and SM_CAP_CSWITCH_JOIN
  are both removed
• Then SM_CAP_PSWITCH is or-ed in

Thus the control is reported as having Capabilities pswitch and pswitch-joined

The result is that tools such as alsamixer then think the control is a Playback control, and other software (such as pulseaudio/pipewire) is similarly fooled (since they key off the same capabilities flags).

From looking at the code, I assume that controls presented by the drivers (in this case simply the standard usb driver presented the controls reported to it by the device) come with no 'direction' (playback or capture) information whatsoever. So the code has to use heuristics (e.g. function base_len) to decide the direction. Naturally some control names are going to mess with these heuristics ...

In this particular case - a microphone - we know that it only has a 'capture' direction, so any control must be related to that direction. Is there anyway the heuristic code / ensuing logic can factor in the uni-directional nature to assume the control is capture rather than playback?