Simplifying the mixer

Joerg Reisenweber joerg at openmoko.org
Thu Jun 12 18:14:10 CEST 2008


Am Do  12. Juni 2008 schrieb andrzej zaborowski:
> On 12/06/2008, Joerg Reisenweber <joerg at openmoko.org> wrote:
> >  bottom line: create a GTA02-soundcard driver, with all the right names in 
it.
> >  Switch from WM8753-driver to this driver.
> >  Deprecate usage of the WM8753-driver for GTA02.
> >  Do all this *now*, because it's an API-break for Apps using alsa-controls
> 
> Please don't, and please also don't let the mixer hardware (wm8753) or
> its spec influence the user-visible control names.  Especially
> register numbers in control names would be strictly a debugging
> feature.  The user doesn't care about this, the user wants to see two
> volume bars named "Headphones" that control the master volume for left
> and eight earpiece and another set of bars for every path that ends at
> headphones jack, but clearly marked as such (as far a the ALSA naming
> standard allows of course).
> 
> This is definitely a task for the mach-gta02.c or neo1973_wm8753.c to
> supply a mapping from the WM8753+LM4857 audio paths to strings
> describing what they actually do.  It needs to also ensure that paths
> that start or end at an input/output which is unconnected on GTA02
> don't appear in the mixer at all.  As far as I can see this is mostly
> how it's implemented now.
> 

Sorry we don't handle any sort of audioPATH here. The path is composed by 
setting properties of technical elements in mixer, and it's these properties 
you see as controls in alsamixer.
Alas there is no simple way to assign a specific mixer-element to a single 
abstract audio-path most of the cases. Though exactly this is done NOW, just 
a pity the assumed pathes DON'T EXIST on our hw (at least not the way the guy 
who invented the names with your idea of pathes in mind assumed they are), 
they are different and may change. However the name of the individual 
control-element stays the same, no matter how our audio-pathes are 
reconfigured - obviously it's a bad idea then to assign a path-related name 
to these controls. The names like they are now, probably assume our BT is the 
system GSM. So no matter what the user expects, he surely doesn't expect to 
get completely missguiding names, however nice and simple they might sound.

Mark Brown has shown up a way to rename the controls depending on scenarios 
(which is another word for a set of audiopathes), and I think this is a very 
clean approach *for simple GUI-based mixer apps* like those you mentioned. 
For "low-level" things like alsamixer though, a much more technical naming, 
that's completely avoiding the concept of pathes, is much more appropriate, 
because alsamixer has no idea of scenarios in he first instance. So you have 
the choice "simple, completely wrong names" or "technical names" for low 
level things. I vote for "technical names" all through, then.


/jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080612/9bd771e8/attachment-0001.pgp 


More information about the openmoko-devel mailing list