[alsa-devel] CMI8788/AV200/Oxygen Volume Controls in alsamixer (oxygen_mixer.c:dac_volume_get())
tiwai at suse.de
Sat Jan 24 11:12:29 CET 2009
At Fri, 23 Jan 2009 11:21:57 -0800,
John Utz wrote:
> [1 <text/plain; iso-8859-1 (quoted-printable)>]
> [2 <text/html; iso-8859-1 (quoted-printable)>]
> -----Original Message-----
> From: Clemens Ladisch [mailto:clemens at ladisch.de]
> Sent: Fri 1/23/2009 6:13 AM
> To: Takashi Iwai
> Cc: ALSA Developers; John Utz
> Subject: Re: [alsa-devel] CMI8788/AV200/Oxygen Volume Controls in alsamixer
> > A solution would be make individual control like "Front", and create a
> > virtual master control.
> I am *not* going to change the driver just to accommodate to alsamixer.
> JU nobody is asking you to, if my employer decides that we will use the card
> (not entirely clear, it's expensive and IMHO the sound quality isnt worth the
> money) then i will be tasked with making this work.
> JU i will figure out a functional solution that allows the CMI8788 to appear
> to our app as a 'ALSA traditional' mixer api, be it compiled code or alsa
> card config fu.
> I am going to change alsamixer to display the channel names (which it
> already knows).
> JU I am thinking that this perspective is not likely to lead to a successful
> JU Do keep in mind that your current implementation *works* for *humans*, they
> can figure out which is the right slider to move.
> JU *Programs* are hosed tho, because they depend on unique control
Well, there are a few issues behind this problem.
- Existing mixer apps handle only mono or pair-stereo volume controls.
- Thus alsa-lib mixer API (or alsamixer) tries to split them up
This works if all the apps cope with this policy -- checking the channel
and appending the channel suffix appropriately. But, in practice,
In addition, there is another thing as "de facto standard":
- A typical mixer app shows one mixer element as the master (e.g. kmix
shows one slider with a left click), and this is *one* slider.
This brings us a question, what is "Master" control. In common sense,
it is a control that covers all levels. And, currently existing apps
expect that this is either a mono or a pair-stereo volume, not
Now what we can do for this? Let all apps compute a mono master
volume based on multi-channel master volumes? Or introduce a virtual
master in the sound subsystem level?
In the case of former solution, it'd be a really hardwork. In the
latter case, a framework is already there in the sound driver core,
and will be a 5-minutes job to adapt it for virtuoso/oxygen. That's
why I suggested it as *a* solution, not *the* solution.
> JU I will save my rant about how misguided it was to put english strings in a
> driver for another day. :-(
> JU We are stuck with it. The only way that will change will be if a new sound
> project where to be invented, just like ALSA replaced OSS.
It's not about putting the english strings. This works fine with
other OS like Windows. The problem comes just along with the
More information about the Alsa-devel