On 12/06/2008, Joerg Reisenweber <[EMAIL PROTECTED]> 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.
