Simplifying the mixer

Mark Brown broonie at opensource.wolfsonmicro.com
Thu Jun 12 15:34:29 CEST 2008


On Thu, Jun 12, 2008 at 01:09:24PM +0200, Joerg Reisenweber wrote:

> I know what the term "sidetone" means (German "Rueckhoerdaempfung" - I'm 
> experienced in telecommunication electronics). My objection was there are 
> several mixer-controlls named "*sidetone*" that do not show up in mixer-spec 
> in any way. 

I don't follow here, sorry - what's "mixer-spec"?

> Our mixer routing setup isn't default (in fact it's completely different to 
> the 'recommended external configuration', as it doesn't use the Vx-codec at 
> all for calls), so it's **very** hard to figure out what might be the real 
> effect these sidetone-controls might have on *our* routing.

Yup, that's not helping at all.

> > If you find things that don't appear to correspond to either the ALSA
> > standard or the chip datasheet then please report them - they certainly
> > should at least be looked at.

> First of all they should correspond to the very way the chip is implemented 
> and used in GTA01/02-design. (there's no use in any control name like "Master 
> Volume"(example), when the so-named control does something completely 
> different. Doesn't help for any app that's parsing names, either)

Yes, that does get confusing.  It's rather unfortunate for this stuff
that ALSA uses control names in the way it does since trying to shoehorn 
things leads to this sort of confusion.

What would probably help a lot here would just be to rename the
headphone and speaker controls to reflect the pins that are being
controlled rather than the functions - this is the approach that some of
the other ASoC drivers have used and is easier to follow.

Thinking about it, it would also be straightforward to add code to ASoC
which will give a mapping of ALSA control names to and from register
bits via a sysfs file.

> To my understanding the alsa-driver is specific to our hw-implementation (or 
> it should be at least), in the sense that GTA01/02 include a OEM-"soundcard" 
> onboard. Sure this OEM-card is based on a standard chip (8753), nevertheless 
> the way the chip is used is OEM and needs a dedicated driver, as I understand 
> it. We don't have a WM8753-soundcard, we have a GTA02-soundcard, and we 
> should use the "right" driver for it. I wouldn't care whether or not this 
> driver makes it upstream.

That was the way people used to write ALSA drivers for embedded audio
stuff - the big problem with that approach is code reuse; there's no
point in people writing the same drivers over and over again to control
the same bits of hardware.

> There's no use in any way to inherit things like 'Voice Sidetone Capture 
> Volume' that do not apply to our design.
> Probably we should map the genuine alsa-names to meet our (different) 
> routing(s), where applicable, and discard all inappropriate names in favour 
> for the chip-spec technical names. For those alsa-names we like to keep 
> (those few that a generic application might want to use), we should create 
> the dictionary I mentioned.

The scenario API[1] will help users here since it includes support for
control aliasing.  It doesn't help the people writing the scenario files
- though codec-specific names for the outputs might be enough to deal with
that.

> 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

If you really want to go down this route it would be much better to just
rename the controls in the existing drivers as a local OpenMoko patch
rather than writing an entirely new sound driver.  Your issue here
appears to be only with the control names so discarding the entire
existing driver seems excessive - the OpenMoko specific code is very
small in comparison to the volume of code required to control the codec
and SoC side.

[1] http://opensource.wolfsonmicro.com/node/22



More information about the openmoko-devel mailing list