Re: Mixer improvements

[Takashi Iwai <tiwai@suse.de>]

At Sun, 11 Sep 2005 12:51:17 +0100,
James Courtier-Dutton wrote:
> 
> Hi,
> 
> See below for current sndrv_ctl_elem_info structure.
> 
> I would like to add to this structure the following elements:
> 1) Unsigned integer index to percent <-> dB function.
> I would implement in alsa-lib an array of functions, each doing a 
> conversion of a different type. This index would select which conversion 
> routine to use for this particular mixer element. A value of 0 in this 
> index would indicate that no conversion function is currently 
> implemented for this mixer control and would therefore be backward 
> compatible as by default, unused integers in a structure are given a 
> value of 0.
> 2) Integer for Analog or Digital path. This will indicate which side of 
> the ADC and DAC converter the mixer control is. This is particularly 
> useful when trying to set mic capture levels, capture limiting and 
> sampling accuracy. 0 = Digital, 1 = Analog
> For example, One would probably want to set the digital(After ADC) mixer 
> controls all to 0dB level, so one gets exact samples from the ADC all 
> the way to the application, but one would want to adjust the mixer 
> controls before the ADC in order to avoid clipping.
> 3) Link information.
> Like USB and HDA sound cards, they have a linked list showing which 
> mixer element is connected to which other mixer element. I would like to 
> implement this for PCI sound cards. Maybe if we used exactly the same 
> method as the USB one, we could
> 
> Points 1 and 2 I would like to implement immeadiately, with points 3 a 
> nice to have.
> 
> 4) Alternatively, we could implement this in alsa-lib, and just add 
> something to the card info structure that would uniquely identify a 
> sound card. e.g. General device name and a unique subdevice ID. So that 
> all the various Audigy 2 cards would use a different config file in 
> alsa-lib. We could make the device name a dir, and the subdevice ID the 
> actual config file.
> 
> Can someone please tell me which is the prefered method 1-3 or 4?

I'm against modifying snd_ctl_elem_info struct.
It's already a mess (see compat_control.c), and adding a new feild
means much more mess.

If an addition is necessary, it'd be better to create another new
struct and ioctl, IMO.


Moreover, we should be careful to handle the value <-> dB conversion.
The dB isn't integer in general, and defining the fixed resolution is
no generic solution.

Adding a dB info into the driver would be required for the USB and HDA
stuff, at least, since they can (or need) retrieve such information
from the hardware directly.
Meanwhile, others are basically given statically - e.g. a simple table
look-up for each ac97 codec.  This isn't necessarily in the kernel
code at all.

So, I think that the implementation of a new struct should be as
simple as possible.  The parameter doesn't need to define the strict
dB expression.  It can be a device-specific expression.
Instead of providing a universal dB expression in the kernel code,
alsa-lib's module module evaluates the device-specific value and
converts to a generic dB value in float.


Just my $0.02, though.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf