Where to put code for a new ioctl.

Where to put code for a new ioctl.

[James Courtier-Dutton]

I am looking at alsa-lib.
./src/control/control_hw.c is there the actual ioctl call goes.
./src/control/control.c calls the routine in control_hw.c
./src/control/hcontrol.c calls the routine in control.c
./src/mixer/simple_none.c handles the call from the user app, it then 
calls ??? hcontrol.c or control.c ?

So, my question is, if I have to write code between the user apps 
request and the ioctl. The purpose of the code is to take the request 
from the user, and then encapsulate it in the ioctl specific format, and 
then call the ioctl. Do I implement this encapsulating code in control.c 
or hcontrol.c ?

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

Re: Where to put code for a new ioctl.

[Takashi Iwai]

At Sun, 27 Nov 2005 11:10:53 +0000,
James Courtier-Dutton wrote:
> 
> I am looking at alsa-lib.
> ./src/control/control_hw.c is there the actual ioctl call goes.
> ./src/control/control.c calls the routine in control_hw.c
> ./src/control/hcontrol.c calls the routine in control.c
> ./src/mixer/simple_none.c handles the call from the user app, it then 
> calls ??? hcontrol.c or control.c ?
> 
> So, my question is, if I have to write code between the user apps 
> request and the ioctl. The purpose of the code is to take the request 
> from the user, and then encapsulate it in the ioctl specific format, and 
> then call the ioctl. Do I implement this encapsulating code in control.c 
> or hcontrol.c ?

I vote for control.c.  But, anyway, I feel that the current
implementation of mixer is too complex.  There are too many layers.

How about to reduce hcontrol stuff?  It's been never used except as a
handle.


BTW, James, please remember that you need a new ioctl just for limited
drivers.  For dB conversion, only usb-audio, hda-codec and possibly
emu10k1 (for user-space controls) would use this ioctl.  The other
drivers don't need this ioctl at all - in other words, the dB
conversion table shouldn't be implemented on the kernel space but on
user space.

So, please consider the above, the existence of user-space dB
conversion, for the further implementation.  i.e. don't assume that
you have always this ioctl for every driver.  Rather it's a rare
case.


Takashi


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

Re: Where to put code for a new ioctl.

[Jaroslav Kysela]

On Mon, 28 Nov 2005, Takashi Iwai wrote:

> At Sun, 27 Nov 2005 11:10:53 +0000,
> James Courtier-Dutton wrote:
> > 
> > I am looking at alsa-lib.
> > ./src/control/control_hw.c is there the actual ioctl call goes.
> > ./src/control/control.c calls the routine in control_hw.c
> > ./src/control/hcontrol.c calls the routine in control.c
> > ./src/mixer/simple_none.c handles the call from the user app, it then 
> > calls ??? hcontrol.c or control.c ?
> > 
> > So, my question is, if I have to write code between the user apps 
> > request and the ioctl. The purpose of the code is to take the request 
> > from the user, and then encapsulate it in the ioctl specific format, and 
> > then call the ioctl. Do I implement this encapsulating code in control.c 
> > or hcontrol.c ?
> 
> I vote for control.c.  But, anyway, I feel that the current
> implementation of mixer is too complex.  There are too many layers.
> 
> How about to reduce hcontrol stuff?  It's been never used except as a
> handle.

It's used for the simple mixer implementation to cache the control 
elements. Yes, the structure might look as complicated, but the mixer is 
complicated. So the structure is:

1) control - raw control API access
2) hcontrol - cached control API access, fast lookups etc...
3) mixer - mixer API
   3a) mixer simple none
   3b) mixer simple abstract

> BTW, James, please remember that you need a new ioctl just for limited
> drivers.  For dB conversion, only usb-audio, hda-codec and possibly
> emu10k1 (for user-space controls) would use this ioctl.  The other
> drivers don't need this ioctl at all - in other words, the dB
> conversion table shouldn't be implemented on the kernel space but on
> user space.

I 100% agree here. The new ioctl will fail or don't give dB info for most 
drivers. The possibility is to emulate the ioctl in control.c for rest 
hardware (probably it's the most easy solution), or leave it to 3b) mixer 
simple abstract layer. 

						Jaroslav

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


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

Re: Where to put code for a new ioctl.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> 
> It's used for the simple mixer implementation to cache the control 
> elements. Yes, the structure might look as complicated, but the mixer is 
> complicated. So the structure is:
> 
> 1) control - raw control API access
> 2) hcontrol - cached control API access, fast lookups etc...
> 3) mixer - mixer API
>    3a) mixer simple none
>    3b) mixer simple abstract
> 
> 
>>BTW, James, please remember that you need a new ioctl just for limited
>>drivers.  For dB conversion, only usb-audio, hda-codec and possibly
>>emu10k1 (for user-space controls) would use this ioctl.  The other
>>drivers don't need this ioctl at all - in other words, the dB
>>conversion table shouldn't be implemented on the kernel space but on
>>user space.
> 
> 
> I 100% agree here. The new ioctl will fail or don't give dB info for most 
> drivers. The possibility is to emulate the ioctl in control.c for rest 
> hardware (probably it's the most easy solution), or leave it to 3b) mixer 
> simple abstract layer. 
> 
> 						Jaroslav
> 

It's alright saying that, but when you come to implement it, you have 
problems.
My aim is this:
1) user app calls snd_mixer_selem_get_playback_dB()
2) alsa-lib retrieves the current value from 
snd_mixer_selem_get_playback_volume()
3) alsa-lib makes a call that returns details of a conversion function 
parameters. (e.g. function type, offset, multiplier, divisor). I am 
intending the function type to be a simple integer index, so that 
alsa-lib know which pre-defined function to use.
4) alsa-lib does the conversion. Example function type: 
dB_gain=(((volume-offset)*multiplier*100)/divisor);
5) alsa-lib returns the dB value to the user app.

The problem is (3).
The low level kernel driver registered the volume control, so only the 
low level driver will actually know what dB scale to apply to it.

I am therefore implementing an ioctl to handle (3) in control.c.
Any low level driver not implementing this ioctl will simply result in 
dB values not being shown in the alsamixer. i.e. current behavior.

(3) can be implemented in a number of different ways. I am intending to 
implement it in as flexible way as possible using TLVs.

The entire list of all function and parameters could all be in alsa-lib 
space, but there is still the requirement for the low level kernel 
driver to select which function, from the list, a particular control 
should use.

I can't see step (3) being achievable without a ioctl.

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

Re: Where to put code for a new ioctl.

[Takashi Iwai]

At Mon, 28 Nov 2005 18:56:27 +0000,
James Courtier-Dutton wrote:
> 
> Jaroslav Kysela wrote:
> > 
> > It's used for the simple mixer implementation to cache the control 
> > elements. Yes, the structure might look as complicated, but the mixer is 
> > complicated. So the structure is:
> > 
> > 1) control - raw control API access
> > 2) hcontrol - cached control API access, fast lookups etc...
> > 3) mixer - mixer API
> >    3a) mixer simple none
> >    3b) mixer simple abstract
> > 
> > 
> >>BTW, James, please remember that you need a new ioctl just for limited
> >>drivers.  For dB conversion, only usb-audio, hda-codec and possibly
> >>emu10k1 (for user-space controls) would use this ioctl.  The other
> >>drivers don't need this ioctl at all - in other words, the dB
> >>conversion table shouldn't be implemented on the kernel space but on
> >>user space.
> > 
> > 
> > I 100% agree here. The new ioctl will fail or don't give dB info for most 
> > drivers. The possibility is to emulate the ioctl in control.c for rest 
> > hardware (probably it's the most easy solution), or leave it to 3b) mixer 
> > simple abstract layer. 
> > 
> > 						Jaroslav
> > 
> 
> It's alright saying that, but when you come to implement it, you have 
> problems.
> My aim is this:
> 1) user app calls snd_mixer_selem_get_playback_dB()
> 2) alsa-lib retrieves the current value from 
> snd_mixer_selem_get_playback_volume()
> 3) alsa-lib makes a call that returns details of a conversion function 
> parameters. (e.g. function type, offset, multiplier, divisor). I am 
> intending the function type to be a simple integer index, so that 
> alsa-lib know which pre-defined function to use.
> 4) alsa-lib does the conversion. Example function type: 
> dB_gain=(((volume-offset)*multiplier*100)/divisor);
> 5) alsa-lib returns the dB value to the user app.
> 
> The problem is (3).
> The low level kernel driver registered the volume control, so only the 
> low level driver will actually know what dB scale to apply to it.

The dB information for most drivers is static.  That is, it doesn't
have to be in kernel space at all.  The whole information is known.

So, what you need is to identify the driver and the matching codec,
and to obtain the dB information (scale, resolution and offset) for
each control element of the given configuration.

In the case of user-space solution, the scenario would be like the
following:
The h/w configuration can be retrieved via cardinfo and card
components (for codec ids, etc).  Then, access to a database on
user-space to obtain the dB information.  The database doesn't have to
be a too complex one.  We can reuse the alsa-lib's config space and
separate files with driver and codec ids, for example.

> I am therefore implementing an ioctl to handle (3) in control.c.
> Any low level driver not implementing this ioctl will simply result in 
> dB values not being shown in the alsamixer. i.e. current behavior.
> 
> (3) can be implemented in a number of different ways. I am intending to 
> implement it in as flexible way as possible using TLVs.

It's fine with TLV.  But please don't implement it on kernel space for
drivers without dynamic configuration.  A user-space database is
much more flexible than strictly bound to kernel drivers.

Also, (4) isn't too easy in some cases.  It's not always logarithmic
linear.  For example, some ac97 codecs have +gain, and it's not the
same curve as the attenuation.  In addition, some codecs have a linear
volume.  This has to be converted to log.


Takashi


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

Re: Where to put code for a new ioctl.

[Liam Girdwood]

On Mon, 2005-11-28 at 20:18 +0100, Takashi Iwai wrote:
> 
> Also, (4) isn't too easy in some cases.  It's not always logarithmic
> linear.  For example, some ac97 codecs have +gain, and it's not the
> same curve as the attenuation.  In addition, some codecs have a linear
> volume.  This has to be converted to log.
> 
> 

To further complicate things, some codecs can even have their gain step
size altered. e.g. gain/attenuation for some volumes can be either in
0.75 or 1.5 dB steps.

Liam



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

Re: Where to put code for a new ioctl.

[James Courtier-Dutton]

Takashi Iwai wrote:
> 
> The dB information for most drivers is static.  That is, it doesn't
> have to be in kernel space at all.  The whole information is known.
> 
> So, what you need is to identify the driver and the matching codec,
> and to obtain the dB information (scale, resolution and offset) for
> each control element of the given configuration.
> 
> In the case of user-space solution, the scenario would be like the
> following:
> The h/w configuration can be retrieved via cardinfo and card
> components (for codec ids, etc).  Then, access to a database on
> user-space to obtain the dB information.  The database doesn't have to
> be a too complex one.  We can reuse the alsa-lib's config space and
> separate files with driver and codec ids, for example.

This all sounds rather messy to me. If we just take the intel8x0 driver 
as an example. It's controls are fixed once the kernel module has 
loaded, but even knowing the controller chip and the ac97 codec being 
used, one still does not have complete information. One has to then take 
into account all the quirks on the different boards.

> 
> 
>>I am therefore implementing an ioctl to handle (3) in control.c.
>>Any low level driver not implementing this ioctl will simply result in 
>>dB values not being shown in the alsamixer. i.e. current behavior.
>>
>>(3) can be implemented in a number of different ways. I am intending to 
>>implement it in as flexible way as possible using TLVs.
> 
> 
> It's fine with TLV.  But please don't implement it on kernel space for
> drivers without dynamic configuration.  A user-space database is
> much more flexible than strictly bound to kernel drivers.
> 
> Also, (4) isn't too easy in some cases.  It's not always logarithmic
> linear.  For example, some ac97 codecs have +gain, and it's not the
> same curve as the attenuation.  In addition, some codecs have a linear
> volume.  This has to be converted to log.
> 
> 
> Takashi
> 
> 

So what about a mix of the two.
1) kernel space adding one extra parameter to each mixer control 
registration. The extra parameter will simply be: index into dB function.
2) alsa-lib then contains a database of all the different conversion 
functions, and simply uses the "index" to select the appropriate 
function for this particular gain control.

This will add minimal complexity to the kernel modules, and at the same 
time simplify the user land code.

Now, I think that the best way for me to get to a balanced view on what 
needs doing in user space, is for me to understand what other features 
apart from dB gain conversion, do we have planned for user space mixers.
I know Jaroslav has been working on lisp config files for the mixer, 
just like we have for the pcm, but I have not seen any detains of what 
he is actually planning to do within the mixer config file.

I suppose one think that might be needed is language options for the 
mixer control names.
What else?

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

Re: Where to put code for a new ioctl.

[Jaroslav Kysela]

On Mon, 28 Nov 2005, James Courtier-Dutton wrote:

> I can't see step (3) being achievable without a ioctl.

I see. You should check the vendor/subvendor/codec and other IDs from the 
driver and then choose the proper conversion table / expression in 
alsa-lib. I added the 'components' field to the control info structure 
some time ago exactly for this purpose. If some identification is missing, 
it should be added to the lowlevel driver.

						Jaroslav

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


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

Re: Where to put code for a new ioctl.

[Takashi Iwai]

At Mon, 28 Nov 2005 21:23:52 +0000,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > 
> > The dB information for most drivers is static.  That is, it doesn't
> > have to be in kernel space at all.  The whole information is known.
> > 
> > So, what you need is to identify the driver and the matching codec,
> > and to obtain the dB information (scale, resolution and offset) for
> > each control element of the given configuration.
> > 
> > In the case of user-space solution, the scenario would be like the
> > following:
> > The h/w configuration can be retrieved via cardinfo and card
> > components (for codec ids, etc).  Then, access to a database on
> > user-space to obtain the dB information.  The database doesn't have to
> > be a too complex one.  We can reuse the alsa-lib's config space and
> > separate files with driver and codec ids, for example.
> 
> This all sounds rather messy to me. If we just take the intel8x0 driver 
> as an example. It's controls are fixed once the kernel module has 
> loaded, but even knowing the controller chip and the ac97 codec being 
> used, one still does not have complete information. One has to then take 
> into account all the quirks on the different boards.

We may add a quirk type to the component field as more identifier.


> >>I am therefore implementing an ioctl to handle (3) in control.c.
> >>Any low level driver not implementing this ioctl will simply result in 
> >>dB values not being shown in the alsamixer. i.e. current behavior.
> >>
> >>(3) can be implemented in a number of different ways. I am intending to 
> >>implement it in as flexible way as possible using TLVs.
> > 
> > 
> > It's fine with TLV.  But please don't implement it on kernel space for
> > drivers without dynamic configuration.  A user-space database is
> > much more flexible than strictly bound to kernel drivers.
> > 
> > Also, (4) isn't too easy in some cases.  It's not always logarithmic
> > linear.  For example, some ac97 codecs have +gain, and it's not the
> > same curve as the attenuation.  In addition, some codecs have a linear
> > volume.  This has to be converted to log.
> > 
> > 
> > Takashi
> > 
> > 
> 
> So what about a mix of the two.
> 1) kernel space adding one extra parameter to each mixer control 
> registration. The extra parameter will simply be: index into dB function.
> 
> 2) alsa-lib then contains a database of all the different conversion 
> functions, and simply uses the "index" to select the appropriate 
> function for this particular gain control.
> 
> This will add minimal complexity to the kernel modules, and at the same 
> time simplify the user land code.

Hmm, but the handling of quirk would be equally complicated since the
swap or removal is done after registration...


Takashi


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