Simplifying the mixer

[Joerg Reisenweber]

Am Do  12. Juni 2008 schrieb Mark Brown:
> 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"?

Sorry, just meant the chip-spec WM8753 papers, especially 
WM8753_control_diag.pdf


> 
> > 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.

Well, i don't suggest to write new drivers. see below


> 
> > 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.

My approach was to use the existing WM8753-driver code and just modify the 
names of controls, add any GTA01/2 specific stuff like switching the external 
amp hp<->spk via cpu-GPIO (clearly *NO* WM8753-domain), and rename the whole 
thing to reflect it's a driver that's not to be used by any other hardware 
than GTA01/2. This could easily be done by a patch, a branch or whatever way 
you guys usually do things like this, thus any development would still happen 
on WM8753, and the changes are included to gta0x-alsa-driver automatically.
Dunno whether there is any SOP for things like this, no kernel-devel 
speaking ;-)

cheers
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/9177bd86/attachment-0001.pgp