Simplifying the mixer

andrzej zaborowski balrogg at gmail.com
Thu Jun 12 23:01:46 CEST 2008


On 12/06/2008, Joerg Reisenweber <joerg at openmoko.org> wrote:
> Let me straighten this out a little more:
>  Our headphones and our speaker "path" share the same physical elements like
>  amplifier and volume control. So there never will be a separate control in
>  alsamixer for master level of headphone and another one for speaker (unless
>  someone will hack the alsa-driver). Instead the one control changes it's
>  meaning depending on another control that actually does the switching
>  hp<->spk.

Well, that's like my desktop: it has a PCM master control that
controls generic playback volume no matter where it goes.  Then it has
one stereo control for the speakers and one for the headphones and
other outputs, the output volume is the product of all the controls on
the path.

> What would you suggest for this very simple(!) case to name the
>  control: "Speaker Vol", "Headphones Vol", "Speaker/Headphones",
>  "OUT1VOL"? The first 3 names are ambiguous or even incorrect, the 4. will give
>  a clue to everyone who is trying to understand what is really going to happen
>  when this control is changed.

"PCM" or "Playback" or something.

>
>  Any higher sophisticated userland app could/should use the scenario services
>  and knowledge about currently active "path" to rename "OUT1VOL"
>  to "Speaker/Headphone Volume", or even provide two distinct
>  controls "Headphone" AND "Speaker" and store the setting of the actually
>  inactive one, while applying the other one to OUT1VOL mixer-element. So "the
>  user" never gets in contact with technical names, while "low level hackers"
>  aren't puzzled by wrong simple path related names.

I don't know.. I use alsamixer and aumix on my desktop, they both work
with the ALSA mixer controls 1:1 - no remapping, there's no reason
alsamixer should be a hacker-only thing on GTA02.

In general I think Linux is more flexible than you're thinking - it
has 10+ years of supporting tons of weird hardware, some drivers share
parts of the code, it knows how to workaround hardware bugs, and also
how to detect hardware and override some behaviours on some specific
models - all this to provide a uniform interface for userspace across
varied hardware.  Supporting many different devices all using a WM8753
chip, each with different things wired to different inputs should
really be no problem for ASoC framework as it's specifically designed
with this in mind.  Supporting GTA01 and GTA02 and beyond in the same
kernel, each with different controls is also no problem for Linux
(it's the OS of choice for a reason).

>  NB: even a cryptic technical name with register-annotation is better than a
>  completely false name, especially for "the user". I doesn't provoke
>  frustration of the kind "It's so simple to understand, but it just doesn't
>  work"
>
>  cheers
>  jOERG
>
>
>  /jOERG
>
>

Cheers
-- 
Please do not print this email unless absolutely necessary. Spread
environmental awareness.



More information about the openmoko-devel mailing list