Mixer improvements

Mixer improvements

[James Courtier-Dutton]

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?

Extract from asound.h:
struct sndrv_ctl_elem_info {
         struct sndrv_ctl_elem_id id;    /* W: element ID */
         enum sndrv_ctl_elem_type type;  /* R: value type - 
SNDRV_CTL_ELEM_TYPE_* */
         unsigned int access;            /* R: value access (bitmask) - 
SNDRV_CTL_ELEM_ACCESS_* */
         unsigned int count;             /* count of values */
         pid_t owner;                    /* owner's PID of this control */
         union {
                 struct {
                         long min;               /* R: minimum value */
                         long max;               /* R: maximum value */
                         long step;              /* R: step (0 variable) */
                 } integer;
                 struct {
                         long long min;          /* R: minimum value */
                         long long max;          /* R: maximum value */
                         long long step;         /* R: step (0 variable) */
                 } integer64;
                 struct {
                         unsigned int items;     /* R: number of items */
                         unsigned int item;      /* W: item number */
                         char name[64];          /* R: value name */
                 } enumerated;
                 unsigned char reserved[128];
         } value;
         union {
                 unsigned short d[4];            /* dimensions */
                 unsigned short *d_ptr;          /* indirect */
         } dimen;
         unsigned char reserved[64-4*sizeof(unsigned short)];
};


-------------------------------------------------------
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

Re: Mixer improvements

[Takashi Iwai]

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

Re: Mixer improvements

[Jaroslav Kysela]

On Mon, 12 Sep 2005, Takashi Iwai wrote:

> > 1) Unsigned integer index to percent <-> dB function.
> > 2) Integer for Analog or Digital path. This will indicate which side of 
> > 3) Link information.
> > 4) Alternatively, we could implement this in alsa-lib, and just add 

I agree that 1 is the main required extension. 2 and 3 are optional in my 
eyes.

> 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.

It's signed integer - fixed float resolution (* 100) in my implementation. 
I think that it's enough for our purpose.

> 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.

I agree, the alsa-lib should have a database containing this static 
information. Also, I think that this information does not belong to the 
universal control API at all. We need to decide, if we need another 
midlevel module providing this information, or in my eyes, better way 
might be to use the hwdep device and pass this information to the user 
space. The alsa-lib modules driving the specific hardware will parse this 
information and do own things with it. Perhaps, we can pass simple text 
from the driver to user space. In this way, the procfs or devfs might be 
used.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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

Re: Mixer improvements

[Takashi Iwai]

At Mon, 12 Sep 2005 14:44:21 +0200 (CEST),
Jaroslav wrote:
> 
> On Mon, 12 Sep 2005, Takashi Iwai wrote:
> 
> > > 1) Unsigned integer index to percent <-> dB function.
> > > 2) Integer for Analog or Digital path. This will indicate which side of 
> > > 3) Link information.
> > > 4) Alternatively, we could implement this in alsa-lib, and just add 
> 
> I agree that 1 is the main required extension. 2 and 3 are optional in my 
> eyes.

Agreed.  2 and 3 don't have to be generic.  Such information is anyway
driver/codec-specific and won't help the usability unless it's cooked
well for easy-to-eat.

(In other word, it's fine to provide 2 and 3 as long as the support
 code in alsa-lib handles them.)


> > 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.
> 
> It's signed integer - fixed float resolution (* 100) in my implementation. 
> I think that it's enough for our purpose.

Ah, OK.

> > 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.
> 
> I agree, the alsa-lib should have a database containing this static 
> information. Also, I think that this information does not belong to the 
> universal control API at all. We need to decide, if we need another 
> midlevel module providing this information, or in my eyes, better way 
> might be to use the hwdep device and pass this information to the user 
> space. The alsa-lib modules driving the specific hardware will parse this 
> information and do own things with it. Perhaps, we can pass simple text 
> from the driver to user space. In this way, the procfs or devfs might be 
> used.

You mean sysfs?  :)

I feel it's easier to stick with the control device because the
information is indeed tightly bound to control elements.
I'm just against modifying the existing snd_ctl_elem_info.


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

Re: Mixer improvements

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Mon, 12 Sep 2005, Takashi Iwai wrote:
> 
> 
>>>1) Unsigned integer index to percent <-> dB function.
>>>2) Integer for Analog or Digital path. This will indicate which side of 
>>>3) Link information.
>>>4) Alternatively, we could implement this in alsa-lib, and just add 
> 
> 
> I agree that 1 is the main required extension. 2 and 3 are optional in my 
> eyes.

Agreed.

> 
> 
>>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.
> 
> 
> It's signed integer - fixed float resolution (* 100) in my implementation. 
> I think that it's enough for our purpose.

I have already checked into the alsa-utils cvs support for this API in 
alsamixer. We just need to add the features to alsa-lib and alsa-driver.

> 
> 
>>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.

> 
> 
> I agree, the alsa-lib should have a database containing this static 
> information. Also, I think that this information does not belong to the 
> universal control API at all. We need to decide, if we need another 
> midlevel module providing this information, or in my eyes, better way 
> might be to use the hwdep device and pass this information to the user 
> space. The alsa-lib modules driving the specific hardware will parse this 
> information and do own things with it. Perhaps, we can pass simple text 
> from the driver to user space. In this way, the procfs or devfs might be 
> used.
> 
> 						Jaroslav
> 

I will take a first bash at it, provide some patch code that we can then 
discuss.

James


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php