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@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 (oxygen_mixer.c:dac_volume_get())
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 outcome. 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 identification.
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, it's not.
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 multi-channel volumes.
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 multi-channel handling.
thanks,
Takashi