[PATCH] Implement support for display of dB gain in alsamixer.

[PATCH] Implement support for display of dB gain in alsamixer.

[James Courtier-Dutton]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

Hi,

Here is a first draft of one possible way to implement dB gain display 
in alsamixer.

This particular method modifies the alsa-driver to alsa-lib API 
interface by modifying one of the structures there.

If alsa-driver does not match alsa-lib, alsamixer fails to work with the 
following error message:
alsamixer: function snd_mixer_load failed: Inappropriate ioctl for device

I have then implemented support for it in the snd-ca0106 driver.
For any sound card that has not yet had the implementation, this results 
in no extra information being displayed in alsamixer.

As one can see, the work required to implement support in any particular 
driver is minimal.

This should be a good place to start discussions.

Any comments?

James

[-- Attachment #2: dBdriver.patch --]
[-- Type: text/x-patch, Size: 1630 bytes --]

Index: alsa-driver/alsa-kernel/include/asound.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/asound.h,v
retrieving revision 1.55
diff -u -r1.55 asound.h
--- alsa-driver/alsa-kernel/include/asound.h	16 Aug 2005 10:32:04 -0000	1.55
+++ alsa-driver/alsa-kernel/include/asound.h	18 Sep 2005 13:21:42 -0000
@@ -844,6 +844,16 @@
 		} bytes;
 		struct sndrv_aes_iec958 iec958;
         } value;                /* RO */
+        union {
+		union {
+			long scale[128]; /* Index into conversion to dB function. */
+			long *scale_ptr;
+		} integer;
+		union {
+			long long scale[64]; /* Index into conversion to dB function. */
+			long long *scale_ptr;
+		} integer64;
+        } scale;                /* RO */
 	struct timespec tstamp;
         unsigned char reserved[128-sizeof(struct timespec)];
 };
Index: alsa-driver/alsa-kernel/pci/ca0106/ca0106_mixer.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ca0106/ca0106_mixer.c,v
retrieving revision 1.7
diff -u -r1.7 ca0106_mixer.c
--- alsa-driver/alsa-kernel/pci/ca0106/ca0106_mixer.c	30 Aug 2005 20:00:46 -0000	1.7
+++ alsa-driver/alsa-kernel/pci/ca0106/ca0106_mixer.c	18 Sep 2005 13:21:42 -0000
@@ -331,7 +331,9 @@
 
         value = snd_ca0106_ptr_read(emu, reg, channel_id);
         ucontrol->value.integer.value[0] = 0xff - ((value >> 24) & 0xff); /* Left */
+	ucontrol->scale.integer.scale[0] = 1;
         ucontrol->value.integer.value[1] = 0xff - ((value >> 16) & 0xff); /* Right */
+	ucontrol->scale.integer.scale[1] = 1;
         return 0;
 }
 

[-- Attachment #3: dBlib.patch --]
[-- Type: text/x-patch, Size: 5047 bytes --]

Index: alsa-lib/include/control.h
===================================================================
RCS file: /cvsroot/alsa/alsa-lib/include/control.h,v
retrieving revision 1.101
diff -u -r1.101 control.h
--- alsa-lib/include/control.h	9 Jun 2005 17:12:08 -0000	1.101
+++ alsa-lib/include/control.h	18 Sep 2005 13:21:21 -0000
@@ -402,6 +402,7 @@
 void snd_ctl_elem_value_set_index(snd_ctl_elem_value_t *obj, unsigned int val);
 int snd_ctl_elem_value_get_boolean(const snd_ctl_elem_value_t *obj, unsigned int idx);
 long snd_ctl_elem_value_get_integer(const snd_ctl_elem_value_t *obj, unsigned int idx);
+long snd_ctl_elem_scale_get_integer(const snd_ctl_elem_value_t *obj, unsigned int idx);
 long long snd_ctl_elem_value_get_integer64(const snd_ctl_elem_value_t *obj, unsigned int idx);
 unsigned int snd_ctl_elem_value_get_enumerated(const snd_ctl_elem_value_t *obj, unsigned int idx);
 unsigned char snd_ctl_elem_value_get_byte(const snd_ctl_elem_value_t *obj, unsigned int idx);
Index: alsa-lib/include/sound/asound.h
===================================================================
RCS file: /cvsroot/alsa/alsa-lib/include/sound/asound.h,v
retrieving revision 1.20
diff -u -r1.20 asound.h
--- alsa-lib/include/sound/asound.h	19 May 2005 16:59:05 -0000	1.20
+++ alsa-lib/include/sound/asound.h	18 Sep 2005 13:21:21 -0000
@@ -839,6 +839,16 @@
 		} bytes;
 		struct sndrv_aes_iec958 iec958;
         } value;                /* RO */
+        union {
+		union {
+			long scale[128]; /* Index into conversion to dB function. */
+			long *scale_ptr;
+		} integer;
+		union {
+			long long scale[64]; /* Index into conversion to dB function. */
+			long long *scale_ptr;
+		} integer64;
+        } scale;                /* RO */
 	struct timespec tstamp;
         unsigned char reserved[128-sizeof(struct timespec)];
 };
Index: alsa-lib/src/control/control.c
===================================================================
RCS file: /cvsroot/alsa/alsa-lib/src/control/control.c,v
retrieving revision 1.107
diff -u -r1.107 control.c
--- alsa-lib/src/control/control.c	28 Jun 2005 10:24:44 -0000	1.107
+++ alsa-lib/src/control/control.c	18 Sep 2005 13:21:21 -0000
@@ -2302,6 +2302,19 @@
 }
 
 /**
+ * \brief Get scale for an entry of a #SND_CTL_ELEM_TYPE_INTEGER CTL element id/value 
+ * \param obj CTL element id/value
+ * \param idx Entry index
+ * \return value for the entry
+ */ 
+long snd_ctl_elem_scale_get_integer(const snd_ctl_elem_value_t *obj, unsigned int idx)
+{
+	assert(obj);
+	assert(idx < sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0]));
+	return obj->scale.integer.scale[idx];
+}
+
+/**
  * \brief Get value for an entry of a #SND_CTL_ELEM_TYPE_INTEGER CTL element id/value 
  * \param obj CTL element id/value
  * \param idx Entry index
Index: alsa-lib/src/mixer/simple_none.c
===================================================================
RCS file: /cvsroot/alsa/alsa-lib/src/mixer/simple_none.c,v
retrieving revision 1.5
diff -u -r1.5 simple_none.c
--- alsa-lib/src/mixer/simple_none.c	23 Jun 2005 07:45:17 -0000	1.5
+++ alsa-lib/src/mixer/simple_none.c	18 Sep 2005 13:21:22 -0000
@@ -78,6 +78,7 @@
 		long min, max;
 		unsigned int channels;
 		long vol[32];
+		long scale[32]; /* scale to use to convert volume to dB */
 		unsigned int sw;
 	} str[2];
 } selem_none_t;
@@ -236,6 +237,11 @@
 		if (idx >= c->values)
 			idx1 = 0;
 		s->str[dir].vol[idx] = to_user(s, dir, c, snd_ctl_elem_value_get_integer(ctl, idx1));
+		s->str[dir].scale[idx] = snd_ctl_elem_scale_get_integer(ctl, idx1);
+	//FIXME:jcd
+	//printf("s:vol=0x%x, scale=0x%x       \n", 
+	//		s->str[dir].vol[idx],
+	//		s->str[dir].scale[idx]);
 	}
 	return 0;
 }
@@ -963,12 +969,46 @@
 	return 0;
 }
 
-static int get_dB_ops(snd_mixer_elem_t *elem ATTRIBUTE_UNUSED,
-		      int dir ATTRIBUTE_UNUSED,
-		      snd_mixer_selem_channel_id_t channel ATTRIBUTE_UNUSED,
-		      long *value ATTRIBUTE_UNUSED)
+static int get_volume_scale(snd_mixer_elem_t *elem, int dir,
+			  snd_mixer_selem_channel_id_t channel, long *value)
 {
-	return -ENXIO;
+	selem_none_t *s = snd_mixer_elem_get_private(elem);
+	if ((unsigned int) channel >= s->str[dir].channels)
+		return -EINVAL;
+	*value = s->str[dir].scale[channel];
+	return 0;
+}
+
+static get_dB_convert(long volume, long scale, long *value)
+{
+	switch (scale) {
+	case 1:  /* Scale from -51.50 dB to +12.00 dB in steps of 0.75 dB. 256 steps. */
+		if (volume == 0) {
+			*value=-9999; /* Muted */
+			break;
+		}
+		*value=(volume * 25) - 5175; /* For ca0106 controls */
+		break;
+	default:
+		return 1;
+	}
+	return 0;
+}
+
+
+static int get_dB_ops(snd_mixer_elem_t *elem,
+		      int dir,
+		      snd_mixer_selem_channel_id_t channel,
+		      long *value)
+{
+	long volume, scale;
+	if (get_volume_ops(elem, dir, channel, &volume)) 
+		return -EINVAL;
+	if (get_volume_scale(elem, dir, channel, &scale)) 
+		return -EINVAL;
+        if (get_dB_convert(volume, scale, value))
+		return -ENXIO;
+	return 0;
 }
 
 static int get_switch_ops(snd_mixer_elem_t *elem, int dir,

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Jaroslav Kysela]

On Sun, 18 Sep 2005, James Courtier-Dutton wrote:

> Hi,
> 
> Here is a first draft of one possible way to implement dB gain display in
> alsamixer.

I would reject it. My comments:

1) breaks backward compatibility
2) I don't like to have this information in the sndrv_ctl_elem_value 
   struct

My idea is to create an optional path between driver and user space to 
give any additional information about controls and perhaps global mixer 
view.

- per control information (new ioctl)

struct sndrv_ctl_elem_addon {
	struct sndrv_ctl_elem_id id;		/* W: element ID */
	unsigned int size;
	void *ptr;
};

I would propose to have this information in a text form parsed in the user 
space (alsa-lib). It will be quite flexible (the old user space binary 
will skip new tokens).

So the addon should return something like (for ADDON_DB):

dB_table -9600,-8000,-6400

(explanation: index to table is the value written to driver, dB in * 100 
form)

or 

dB_min -9600
dB_max -6400
dB_step 1600

or

dB_range -9600,-6400,1600

(explanation: min,max,step)

And some complex addon description (with routing description):

mixer_block
dB_range -9600,0,2000
rt_in "PCM Plaback Volume",0
rt_out "Master Playback Volume",0
rt_cond_out xy
/mixer_block

etc. we need to define the syntax for signal routing description...

- global mixer information

Again, I would propose a text presentation. Actually, I'm not sure what 
fits to this section, we can implement it on demand. Perhaps some complex 
routing stuff etc.

						Jaroslav

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


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Takashi Iwai]

At Mon, 19 Sep 2005 15:36:21 +0200 (CEST),
Jaroslav wrote:
> 
> On Sun, 18 Sep 2005, James Courtier-Dutton wrote:
> 
> > Hi,
> > 
> > Here is a first draft of one possible way to implement dB gain display in
> > alsamixer.
> 
> I would reject it. My comments:
> 
> 1) breaks backward compatibility
> 2) I don't like to have this information in the sndrv_ctl_elem_value 
>    struct

I appreciate James' work, but I must agree with Jaroslav on both
points.  1 can be fixed relatively easily, but still it will end up
with adding more messes in other parts referring this struct
(e.g. 32/64bit compat layer).   Also, this information doesn't have to
be passed at each time.  It would be necessary only once at
initialization, assuming that the dB table is constant during the
operation.

(BTW, we should remove the comment /* RO */ there...)


> My idea is to create an optional path between driver and user space to 
> give any additional information about controls and perhaps global mixer 
> view.
> 
> - per control information (new ioctl)
> 
> struct sndrv_ctl_elem_addon {
> 	struct sndrv_ctl_elem_id id;		/* W: element ID */
> 	unsigned int size;
> 	void *ptr;
> };
> 
> I would propose to have this information in a text form parsed in the user 
> space (alsa-lib). It will be quite flexible (the old user space binary 
> will skip new tokens).

That sounds fine.

> So the addon should return something like (for ADDON_DB):
> 
> dB_table -9600,-8000,-6400
> 
> (explanation: index to table is the value written to driver, dB in * 100 
> form)
> 
> or 
> 
> dB_min -9600
> dB_max -6400
> dB_step 1600
> 
> or
> 
> dB_range -9600,-6400,1600
> 
> (explanation: min,max,step)
> 
> And some complex addon description (with routing description):
> 
> mixer_block
> dB_range -9600,0,2000
> rt_in "PCM Plaback Volume",0
> rt_out "Master Playback Volume",0
> rt_cond_out xy
> /mixer_block
> 
> etc. we need to define the syntax for signal routing description...

Or, how about to define a struct like
{
	snd_ctl_elem_id_t id;
	char key[KEY_SIZE];
	unsigned int size;
	char *value;
}
so that the caller always asks with the certain key?


Takashi


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Jaroslav Kysela]

On Mon, 19 Sep 2005, Takashi Iwai wrote:

> Or, how about to define a struct like
> {
> 	snd_ctl_elem_id_t id;
> 	char key[KEY_SIZE];
> 	unsigned int size;
> 	char *value;
> }
> so that the caller always asks with the certain key?

It's also quite good method, but it avoids having multiple blocks with 
same keys. For example:

block1-mixer
key1
key2
/block1-mixer
block2-pcm
key1
key2
/block2-pcm

Maybe adding 'char group[GROUP_SIZE]' to the structure will help us.

Also, we should consider to give a possibility to obtain the full list of 
groups/keys to applications / alsa-lib. If we give the full contents the 
applications can do rest otherwise the driver must implement an arbiter 
which collects this information.

I would vote to keep the kernel space as simple as possible and give the 
whole contents to apps. They can implement reading/caching/filtering 
themselves.

						Jaroslav

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


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Takashi Iwai]

At Mon, 19 Sep 2005 17:36:22 +0200 (CEST),
Jaroslav wrote:
> 
> On Mon, 19 Sep 2005, Takashi Iwai wrote:
> 
> > Or, how about to define a struct like
> > {
> > 	snd_ctl_elem_id_t id;
> > 	char key[KEY_SIZE];
> > 	unsigned int size;
> > 	char *value;
> > }
> > so that the caller always asks with the certain key?
> 
> It's also quite good method, but it avoids having multiple blocks with 
> same keys. For example:
> 
> block1-mixer
> key1
> key2
> /block1-mixer
> block2-pcm
> key1
> key2
> /block2-pcm
> 
> Maybe adding 'char group[GROUP_SIZE]' to the structure will help us.

I feel a group field would be overcomplex.
The beauty of this record is its simplicity.

Maybe the principle question is whether we really need a structural
data or not.  My proposal above assumes that the data area all simple
attributes, mapped 1-1.  If the requested data isn't so easy, the
above has rare merits.

> Also, we should consider to give a possibility to obtain the full list of 
> groups/keys to applications / alsa-lib. If we give the full contents the 
> applications can do rest otherwise the driver must implement an arbiter 
> which collects this information.

In the case of the explicity key-value record, it's easy.  We can
define a special key, e.g. "list", to return the list of keys, so no
API extension is needed.

> I would vote to keep the kernel space as simple as possible and give the 
> whole contents to apps. They can implement reading/caching/filtering 
> themselves.

Agreed.


Takashi


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> It's also quite good method, but it avoids having multiple blocks with 
> same keys. For example:
> 
> block1-mixer
> key1
> key2
> /block1-mixer
> block2-pcm
> key1
> key2
> /block2-pcm
> 

This might be nice...looks more and more like XML all the time. ;-)

You might laugh, but getting the kernel to simply build an xml file that 
it then sends to user space is not that difficult. Then one could use 
the bloated xml parsers in user space, and therefore keeping the kernel 
small.

We could even have the control get/set using xml as well.
So, the above in xml:

<block1-mixer>
<key1>some value</key1>
<key2>some other value</key2>
</block1-mixer>
<block2-pcm>
<key1>some value</key1>
<key2>some other value</key2>
</block2-pcm>


Now, we would have to allow for the possible dynamic adding and removal 
of controls, for example, when using qlo10k1 to add a new effect to the 
Audigy 2 DSP.

The mixer api does not have to be high performance, and using XML would 
be endlessly extensible and backward compatible.

Another alternative would be to use the sys filesystem to transfer the 
information. The nesting would be handled using subdirectories, and the 
keys themselves would be individual files in the sys filesystem.
So, representing the above, the sys fs would contain a dir containing:
block1-mixer
block2-pcm

In the block1-mixer dir, one would have the files:
key1
key2
and the contents of the file would be the value of that parameter.

The alsa-lib would just scan the sys file system with subdirectories and 
only use the keys it could understand.

Some keys would be read only, some read/write.
I.e. the db scale key would be read only, but the gain variable would be r/w

I think that the kernel would be happier with us using the sys fs 
instead of xml.

The only other thing we have to consider is the mixer events method.

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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Jaroslav Kysela]

On Mon, 19 Sep 2005, Takashi Iwai wrote:

> > which collects this information.
> 
> In the case of the explicity key-value record, it's easy.  We can
> define a special key, e.g. "list", to return the list of keys, so no
> API extension is needed.
> 
> > I would vote to keep the kernel space as simple as possible and give the 
> > whole contents to apps. They can implement reading/caching/filtering 
> > themselves.
> 
> Agreed.

Ok, good ideas. I would propose this final API:

1) one key with specific delimiters like:

list		# list everything (all keys)
list/master	# list only master keys (mixer, pcm etc.)
list/mixer	# list only mixer keys
list/pcm
mixer/dB_range	# get value for mixer - dB_range
mixer/abcd
pcm/connector

2) textual representation of values

So, we need to describe the keys and value meaning and then implement it
in the driver code.

						Jaroslav

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


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Clemens Ladisch]

Jaroslav Kysela wrote:
> On Mon, 19 Sep 2005, Takashi Iwai wrote:
> > > I would vote to keep the kernel space as simple as possible and give the
> > > whole contents to apps. They can implement reading/caching/filtering
> > > themselves.
> >
> > Agreed.

Too.

> Ok, good ideas. I would propose this final API:
>
> 1) one key with specific delimiters like:
>
> list		# list everything (all keys)
> list/master	# list only master keys (mixer, pcm etc.)
> list/mixer	# list only mixer keys
> list/pcm

This is _not_ a simple API.  AFAICS the idea was to have just one big
string/blob containing all descriptions, and to let the lib or
applications do the listing/searching/etc.

Accessing specific keys (elements) would be needed only if something
wasn't read only.

> 2) textual representation of values
>
> So, we need to describe the keys and value meaning and then implement it
> in the driver code.

The driver wouldn't need to implement much, except in cases like the
USB driver that has to derive this information from the USB
descriptors.


Regards,
Clemens



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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Jaroslav Kysela]

On Tue, 20 Sep 2005, Clemens Ladisch wrote:

> Jaroslav Kysela wrote:
> > On Mon, 19 Sep 2005, Takashi Iwai wrote:
> > > > I would vote to keep the kernel space as simple as possible and give the
> > > > whole contents to apps. They can implement reading/caching/filtering
> > > > themselves.
> > >
> > > Agreed.
> 
> Too.
> 
> > Ok, good ideas. I would propose this final API:
> >
> > 1) one key with specific delimiters like:
> >
> > list		# list everything (all keys)
> > list/master	# list only master keys (mixer, pcm etc.)
> > list/mixer	# list only mixer keys
> > list/pcm
> 
> This is _not_ a simple API.  AFAICS the idea was to have just one big
> string/blob containing all descriptions, and to let the lib or
> applications do the listing/searching/etc.
> 
> Accessing specific keys (elements) would be needed only if something
> wasn't read only.

You need also take in account that keys might be added/removed at runtime.
The question is still to have:

1) manager code in the midlevel to register keys from drivers and do 
   lookups; in this case the drivers will register the keys
2) leave things simple for midlevel and the ioctl will be directly mapped 
   to the driver code (the blob version of ioctl); in this case the driver 
   must handle all things like memory allocation, key changes etc.

						Jaroslav

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


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

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[James Courtier-Dutton]

Jaroslav Kysela wrote:

>On Tue, 20 Sep 2005, Clemens Ladisch wrote:
>
>  
>
>>Jaroslav Kysela wrote:
>>    
>>
>>>On Mon, 19 Sep 2005, Takashi Iwai wrote:
>>>      
>>>
>>>>>I would vote to keep the kernel space as simple as possible and give the
>>>>>whole contents to apps. They can implement reading/caching/filtering
>>>>>themselves.
>>>>>          
>>>>>
>>>>Agreed.
>>>>        
>>>>
>>Too.
>>
>>    
>>
>>>Ok, good ideas. I would propose this final API:
>>>
>>>1) one key with specific delimiters like:
>>>
>>>list		# list everything (all keys)
>>>list/master	# list only master keys (mixer, pcm etc.)
>>>list/mixer	# list only mixer keys
>>>list/pcm
>>>      
>>>
>>This is _not_ a simple API.  AFAICS the idea was to have just one big
>>string/blob containing all descriptions, and to let the lib or
>>applications do the listing/searching/etc.
>>
>>Accessing specific keys (elements) would be needed only if something
>>wasn't read only.
>>    
>>
>
>You need also take in account that keys might be added/removed at runtime.
>The question is still to have:
>
>1) manager code in the midlevel to register keys from drivers and do 
>   lookups; in this case the drivers will register the keys
>2) leave things simple for midlevel and the ioctl will be directly mapped 
>   to the driver code (the blob version of ioctl); in this case the driver 
>   must handle all things like memory allocation, key changes etc.
>
>						Jaroslav
>  
>

I think that a simple TLV(type, length, value) approach might be more 
efficient for kernel -> alsa-lib info passing.
The message can easily be made hyrachical. One starts with one TLV as a 
wrapper around all information passed. Inside that TLV will be other 
TLVs, and inside those others. This allows the alsa-lib to simply skip 
values it does not yet know about. We can even use a TLV in the request 
from alsa-lib to the kernel.

The T(Type) value is a simple 32bit integer. The receiving function 
simply uses a lookup to find the parameter name, and also the type of 
the value, e.g. Integer, string etc.

For an example of a protocol already using this approach, look at the 
RFCs for RADIUS.

James



*
*


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[Takashi Iwai]

At Thu, 06 Oct 2005 13:54:37 +0100,
James Courtier-Dutton wrote:
> 
> Jaroslav Kysela wrote:
> 
> >On Tue, 20 Sep 2005, Clemens Ladisch wrote:
> >
> >  
> >
> >>Jaroslav Kysela wrote:
> >>    
> >>
> >>>On Mon, 19 Sep 2005, Takashi Iwai wrote:
> >>>      
> >>>
> >>>>>I would vote to keep the kernel space as simple as possible and give the
> >>>>>whole contents to apps. They can implement reading/caching/filtering
> >>>>>themselves.
> >>>>>          
> >>>>>
> >>>>Agreed.
> >>>>        
> >>>>
> >>Too.
> >>
> >>    
> >>
> >>>Ok, good ideas. I would propose this final API:
> >>>
> >>>1) one key with specific delimiters like:
> >>>
> >>>list		# list everything (all keys)
> >>>list/master	# list only master keys (mixer, pcm etc.)
> >>>list/mixer	# list only mixer keys
> >>>list/pcm
> >>>      
> >>>
> >>This is _not_ a simple API.  AFAICS the idea was to have just one big
> >>string/blob containing all descriptions, and to let the lib or
> >>applications do the listing/searching/etc.
> >>
> >>Accessing specific keys (elements) would be needed only if something
> >>wasn't read only.
> >>    
> >>
> >
> >You need also take in account that keys might be added/removed at runtime.
> >The question is still to have:
> >
> >1) manager code in the midlevel to register keys from drivers and do 
> >   lookups; in this case the drivers will register the keys
> >2) leave things simple for midlevel and the ioctl will be directly mapped 
> >   to the driver code (the blob version of ioctl); in this case the driver 
> >   must handle all things like memory allocation, key changes etc.
> >
> >						Jaroslav
> >  
> >
> 
> I think that a simple TLV(type, length, value) approach might be more 
> efficient for kernel -> alsa-lib info passing.
> The message can easily be made hyrachical. One starts with one TLV as a 
> wrapper around all information passed. Inside that TLV will be other 
> TLVs, and inside those others. This allows the alsa-lib to simply skip 
> values it does not yet know about. We can even use a TLV in the request 
> from alsa-lib to the kernel.
> 
> The T(Type) value is a simple 32bit integer. The receiving function 
> simply uses a lookup to find the parameter name, and also the type of 
> the value, e.g. Integer, string etc.
> 
> For an example of a protocol already using this approach, look at the 
> RFCs for RADIUS.

I think it's OK to use such a protocol, as long as the kernel
implemention is simple.  Maybe less allergy than XML texts :)
One-to-one mapping would be the easiest for the driver side.
And, above all, it's driver specific how complex it will be.
Not many drivers require the dynamic topology information.


My concern about the new ioctl is: Avoid architecture dependency.
It implies:
  - Don't use union.
  - Don't use long.
  - Don't use long long.
  - Don't use bit fields.
  - Avoid pointer as much as possible.
  - Consider the alignment.

This is one of the reasons why I don't want to merge the dB attribute
into snd_ctl_elem_info/value.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [PATCH] Implement support for display of dB gain in alsamixer.

[James Courtier-Dutton]

Takashi Iwai wrote:
>>I think that a simple TLV(type, length, value) approach might be more 
>>efficient for kernel -> alsa-lib info passing.
>>The message can easily be made hyrachical. One starts with one TLV as a 
>>wrapper around all information passed. Inside that TLV will be other 
>>TLVs, and inside those others. This allows the alsa-lib to simply skip 
>>values it does not yet know about. We can even use a TLV in the request 
>>from alsa-lib to the kernel.
>>
>>The T(Type) value is a simple 32bit integer. The receiving function 
>>simply uses a lookup to find the parameter name, and also the type of 
>>the value, e.g. Integer, string etc.
>>
>>For an example of a protocol already using this approach, look at the 
>>RFCs for RADIUS.
> 
> 
> I think it's OK to use such a protocol, as long as the kernel
> implemention is simple.  Maybe less allergy than XML texts :)
> One-to-one mapping would be the easiest for the driver side.
> And, above all, it's driver specific how complex it will be.
> Not many drivers require the dynamic topology information.
> 
> 
> My concern about the new ioctl is: Avoid architecture dependency.
> It implies:
>   - Don't use union.
>   - Don't use long.
>   - Don't use long long.
>   - Don't use bit fields.
>   - Avoid pointer as much as possible.
>   - Consider the alignment.
> 
> This is one of the reasons why I don't want to merge the dB attribute
> into snd_ctl_elem_info/value.
> 
> 
> Takashi
> 
> 

Ok, so I am going to implement a new IOCTL that will use TLVs.
The first implementation will be used to support the dB gain information 
passing, but it will be flexible enough to request any information needed.

James


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click