[alsa-devel] Splitting out controls

[Takashi Iwai]

On Fri, 16 Oct 2015 16:49:25 +0200,
Pierre-Louis Bossart wrote:
> 
> > We actively enable and advocate that people with limited knowledge can
> > 'mess around mixer controls'. That's why we have an alsamixer
> > application in the first place, and teach people how to use it.
> 
> What you are describing is the traditional approach where the number of 
> controls is limited, a couple of switches here and a set of volume 
> controls there.
> With new devices having mixers all over the place, be it in codecs or 
> DSPs, it's not uncommon to have several hundred controls. There is no 
> way users will be able to find out on their own what values they should 
> use and it would be misleading to think developers are able to identify 
> all lethal combinations of settings. We've also moved all these control 
> settings from kernel to userspace to avoid hardcoding values that are 
> platform specific.

Right, and this is the problem.  The system integration information
isn't the thing a typical user would need to handle.

OK, we can leave them in user space.  It's more flexible, yes.  But
it's a bad design if a *normal* user is allowed and needs to handle
all these.  A normal user needs (and is allowed) only limited presets;
your car won't allow you accessing hundreds of knobs, e.g. a child on
a rear seat suddenly triggers the turbo-jump button in combination
with a back-fire while driving on a highway :)

> Bottom line we have to move to profiles, stop guessing values based on 
> control names or avoid letting users poke random values in alsamixer. 
> This just doesn't scale any more. thinking that the alsamixer 
> command-line remains the default user-facing interface moving forward is 
> just not right, it's a developer tool.

Well, it doesn't matter whether it's alsamixer or whatever program.
The point is that *any* user program might screw up things easily,
even if it's not intentional.

For Android, it wasn't a big issue, so far, just because only few
people touch the audio setup manually.  But now the former embedded
things get more migrated to the desktop scenes, and it's pretty normal
that a user just runs normal PA and ALSA apps with it nowadays like
PC.  It'll get more and more in the next years.

So, yes, we have profiles to manage the setups in user-space.  This is
very good, scalable, per se.  The problem is, however, rather how to
harden this management.


I still think that the driver can give the first-level filter or
permission isolation.  It should be doable also in topology f/w, in
theory.

Then, we can think of more hardening in user-space side on top of it.
For example, running sound (or UCM) daemon with a privileged user, and
let it alone managing the sensitive sound setup while a normal user is
allowed to adjust only limited presets given by the profile.

Just my $0.02, currently floating on my fuzzy head in bed.


Takashi