[pulseaudio-discuss] Why doesn't mixer control (values) have some kind of locking mechanism? (mutex?)

[Tom Yan]

Hi all,

I just wonder if it's a "no one cares" or a "no one was aware of it"
issue (or maybe both?).

When you change (integer) values (e.g. volume) of a mixer control, it
usually (if not always) involves calling two functions/methods of a
snd_kcontrol_new, which are get and put, in order to do relative
volume adjustments. (Apparently it is often done relatively even if we
have absolute values, for reasons.)

While these two "actions" can be and probably are mostly "atomic"
(with the help of mutex) in the kernel drivers *respectively*, they
are not and cannot be atomic as a whole.

This won't really be an issue when the actions (either for one or
multiple channels) are done "synchronously" in *one* program run (e.g.
amixer -c STX set Master 1+). However, if such a program run is issued
multiple times "asynchronously" (e.g. binding it to some
XF86Audio{Raise,Lower}Volume scroll wheel), volume adjustment becomes
a total mess / failure.

If it isn't obvious enough. it could happen like the following:
get1(100 100)
set1(101 100)
get2(101 100)
set2(102 100)
...

Or worse:
get1(100 100)
get2(100 100)
set1(101 100)
set2(100 101)
...

Not only that it may/will not finish the first set of adjustments for
all channels before the second, get() from the second set could happen
before set() from the first, reverting the effect of the earlier
one(s).

Certainly one can use something like `flock` with amixer to make sure
the atomicity of each issue/run, but not only that it looks silly and
primitive, we don't always manipulate the mixer control with an
"executable". For example, this weird issue in pulseaudio is probably
related: https://bugs.freedesktop.org/show_bug.cgi?id=92717

So I wonder, is there a particular reason that mixer control doesn't
possess some form of lock, which allows any form of userspace
manipulation to lock it until what should be / is considered atomic is
finished?