[GSoC 2021] Project Proposal

[Christos Margiolis]

On Mon, Mar 22, 2021 at 08:41:20AM -0700, Chris wrote:
> Every version of mixer that I have run keeps state in /var/db/mixerN-state:
> vol 100:100 pcm 100:100
> where N is (0-9) which represents a previous state. This has been the case
> for
> as long as I can remember. It's much the same WiFi lease(s). Unless I'm
> missing
> something IMHO it's current incarnation seems trivial to work with /
> manipulate.
> One might consider using JSON notation in it to allow for more advanced
> features
> and manipulation / reading / status I suppose.
> I'm not trying to take the wind out of your sails, or anything. Just sharing
> my own personal observation. :-)
>
> --Chris

Interesting, I didn't really know about that, so I'll have to look more into it
for sure. In any case, I still think my main argument stands that a library
which can be used by all userland programs that might want to have access
to the mixer will be of benefit.

I've already mentioned a few use cases in my initial email. Even in the case
that you outlined - the state already being cached in `/var/db/mixerN-state` -
I think that libmixer(3) could provide with functions that deal with those files,
instead of having the programmer find ways to deal with them.

mixer(8) at the moment still doesn't have the option to mute/unmute the
mixer even with those files existing, so having a library handle all
that stuff, will make mixer(8) basically a frontend for the library and
will have cleaner code. And as I've already said in the previous email, other
programs such as MixerTUI could use the library too. I think that makes
things more extensible; after all, many FreeBSD programs already follow
that design (library + a frontend for it).

----------------------------------------------
Christos Margiolis <christos at christosmarg.xyz>