how to define a 2-index control element?

how to define a 2-index control element?

[Paul Davis]

i'm looking at the control API, and i can't see how to define a
control that requires 2 values in order to read or write the control. 

there seems to be an assumption that a control element maps 1:1 onto a
hardware entity. i want (need) to create a control element that is
more flexible than that. the basic idea is:

         control->value.integer.value[0] = source;
         control->value.integer.value[1] = destination;
	 
	 snd_ctl_read (...)

or:

         control->value.integer.value[0] = source;
         control->value.integer.value[1] = destination;
         control->value.integer.value[3] = gain;

	 snd_ctl_write (...)

am i missing something really simple?

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Abramo Bagnara]

Paul Davis wrote:
> 
> i'm looking at the control API, and i can't see how to define a
> control that requires 2 values in order to read or write the control.
> 
> there seems to be an assumption that a control element maps 1:1 onto a
> hardware entity. i want (need) to create a control element that is
> more flexible than that. the basic idea is:
> 
>          control->value.integer.value[0] = source;
>          control->value.integer.value[1] = destination;
> 
>          snd_ctl_read (...)
> 
> or:
> 
>          control->value.integer.value[0] = source;
>          control->value.integer.value[1] = destination;
>          control->value.integer.value[3] = gain;
> 
>          snd_ctl_write (...)
> 
> am i missing something really simple?
> 

I suggest you to use the field index of struct sndrv_ctl_elem_id (one
byte per dimension).

id.index = (source << 8) | destination;


-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Paul Davis]

>I suggest you to use the field index of struct sndrv_ctl_elem_id (one
>byte per dimension).
>
>id.index = (source << 8) | destination;

but there are 1400+ possible id's ...

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Jaroslav Kysela]

On Sun, 5 May 2002, Paul Davis wrote:

> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
> >byte per dimension).
> >
> >id.index = (source << 8) | destination;
> 
> but there are 1400+ possible id's ...

I agree with Abramo. We can eventually optimize code to handle such amount 
of controls.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Paul Davis]

>On Sun, 5 May 2002, Paul Davis wrote:
>
>> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
>> >byte per dimension).
>> >
>> >id.index = (source << 8) | destination;
>> 
>> but there are 1400+ possible id's ...
>
>I agree with Abramo. We can eventually optimize code to handle such amount 
>of controls.

there's no reason to do that. if you're going to require that the user
merge two values into a single variable (as above), the user can put
the merged result in control->value.integer.value[0]. i just wanted a
way to avoid the user having to do this, because otherwise, it will be
impossible to ever build an automated GUI for the control (you'll
never be able to figure out how to generate the correct values from
the control API's description of the control).

in addition, no automated GUI is possible with 1400+ controls given
the current API. 

in short, i really do not want to implement the H-DSP driver with this
kind of control over the matrix mixer. i raised this issue a month or
two ago, and there was (implicit) agreement then that it was silly to
represent all possible combinations with a 1:1 mapping between ALSA
controls and source/destination pairs.

i guess i'll continue on trying to think of a different way to do
this. but it seems to me that if the control API cannot support
controls that need user data to read/write them, then we need to fix
the control API.

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Jaroslav Kysela]

On Sun, 5 May 2002, Paul Davis wrote:

> >On Sun, 5 May 2002, Paul Davis wrote:
> >
> >> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
> >> >byte per dimension).
> >> >
> >> >id.index = (source << 8) | destination;
> >> 
> >> but there are 1400+ possible id's ...
> >
> >I agree with Abramo. We can eventually optimize code to handle such amount 
> >of controls.
> 
> there's no reason to do that. if you're going to require that the user
> merge two values into a single variable (as above), the user can put
> the merged result in control->value.integer.value[0]. i just wanted a
> way to avoid the user having to do this, because otherwise, it will be
> impossible to ever build an automated GUI for the control (you'll
> never be able to figure out how to generate the correct values from
> the control API's description of the control).

Do we need this? We need to drive hardware via the control API. So each 
controlled elements must be mapped to the user space. In user space, we 
can do more complex remapping for some GUIs in alsa-lib.

> in addition, no automated GUI is possible with 1400+ controls given
> the current API. 
> 
> in short, i really do not want to implement the H-DSP driver with this
> kind of control over the matrix mixer. i raised this issue a month or
> two ago, and there was (implicit) agreement then that it was silly to
> represent all possible combinations with a 1:1 mapping between ALSA
> controls and source/destination pairs.
> 
> i guess i'll continue on trying to think of a different way to do
> this. but it seems to me that if the control API cannot support
> controls that need user data to read/write them, then we need to fix
> the control API.

If you use another system, you'll lose:

- locking of elementary controls
- notification of changes for elementary controls

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Paul Davis]

>> there's no reason to do that. if you're going to require that the user
>> merge two values into a single variable (as above), the user can put
>> the merged result in control->value.integer.value[0]. i just wanted a
>> way to avoid the user having to do this, because otherwise, it will be
>> impossible to ever build an automated GUI for the control (you'll
>> never be able to figure out how to generate the correct values from
>> the control API's description of the control).
>
>Do we need this? We need to drive hardware via the control API. So each 
>controlled elements must be mapped to the user space. In user space, we 
>can do more complex remapping for some GUIs in alsa-lib.

for all the existing controls i've looked at, the existing API seems
capable of telling a user-space application everything it needs to
know about the control in order to usefully control it. in fact,
several elements of the control API appear to be based around
precisely this idea.

this seems like too good a feature thing to give up unless really necessary.

>> i guess i'll continue on trying to think of a different way to do
>> this. but it seems to me that if the control API cannot support
>> controls that need user data to read/write them, then we need to fix
>> the control API.
>
>If you use another system, you'll lose:
>
>- locking of elementary controls
>- notification of changes for elementary controls

i wasn't planning on going outside the control API. i just need some
other way of doing things. As it is, user space can pass multiple data
into the driver via the control->value union. Its just that there is
no way for the control API to tell user space that this is what it
expects. Code written by someone who knows how to use this control
will work just fine, but naive code that thinks it can find out about
a control from the API will not be successful.

right now the API doesn't seem to support the idea that a "read" of a
control requires specific data from the user. is this such a terrible
thing to add?

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Jaroslav Kysela]

On Mon, 6 May 2002, Paul Davis wrote:

> >> there's no reason to do that. if you're going to require that the user
> >> merge two values into a single variable (as above), the user can put
> >> the merged result in control->value.integer.value[0]. i just wanted a
> >> way to avoid the user having to do this, because otherwise, it will be
> >> impossible to ever build an automated GUI for the control (you'll
> >> never be able to figure out how to generate the correct values from
> >> the control API's description of the control).
> >
> >Do we need this? We need to drive hardware via the control API. So each 
> >controlled elements must be mapped to the user space. In user space, we 
> >can do more complex remapping for some GUIs in alsa-lib.
> 
> for all the existing controls i've looked at, the existing API seems
> capable of telling a user-space application everything it needs to
> know about the control in order to usefully control it. in fact,
> several elements of the control API appear to be based around
> precisely this idea.
> 
> this seems like too good a feature thing to give up unless really necessary.
> 
> >> i guess i'll continue on trying to think of a different way to do
> >> this. but it seems to me that if the control API cannot support
> >> controls that need user data to read/write them, then we need to fix
> >> the control API.
> >
> >If you use another system, you'll lose:
> >
> >- locking of elementary controls
> >- notification of changes for elementary controls
> 
> i wasn't planning on going outside the control API. i just need some
> other way of doing things. As it is, user space can pass multiple data
> into the driver via the control->value union. Its just that there is
> no way for the control API to tell user space that this is what it
> expects. Code written by someone who knows how to use this control
> will work just fine, but naive code that thinks it can find out about
> a control from the API will not be successful.
> 
> right now the API doesn't seem to support the idea that a "read" of a
> control requires specific data from the user. is this such a terrible
> thing to add?

We cannot preserve data without extra parsing the address of single
control with your proposal. I speak about alsactl for example. The
question is, if it's really necessary to enhance address of value when it
can be easily encapsulated to current index value. Also, driving of 1400+
controls requires some filters on the user space side, so speaking about
an universal visualizer of such controls is not probably a great idea.

We can eventually add a hint for user space to the control field name
(44 chars is enough for suffix like '[2DM]' representing 2-dimensional
matrix).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Takashi Iwai]

At Sun, 05 May 2002 21:32:12 -0400,
Paul Davis wrote:
> 
> >On Sun, 5 May 2002, Paul Davis wrote:
> >
> >> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
> >> >byte per dimension).
> >> >
> >> >id.index = (source << 8) | destination;
> >> 
> >> but there are 1400+ possible id's ...
> >
> >I agree with Abramo. We can eventually optimize code to handle such amount 
> >of controls.
> 
> there's no reason to do that. if you're going to require that the user
> merge two values into a single variable (as above), the user can put
> the merged result in control->value.integer.value[0]. i just wanted a
> way to avoid the user having to do this, because otherwise, it will be
> impossible to ever build an automated GUI for the control (you'll
> never be able to figure out how to generate the correct values from
> the control API's description of the control).
> 
> in addition, no automated GUI is possible with 1400+ controls given
> the current API. 
> 
> in short, i really do not want to implement the H-DSP driver with this
> kind of control over the matrix mixer. i raised this issue a month or
> two ago, and there was (implicit) agreement then that it was silly to
> represent all possible combinations with a 1:1 mapping between ALSA
> controls and source/destination pairs.

the question is whether we do mapping on kernel or user space.
Abramo's proposal means to do this on application side and it will
need no change for API itself.

of course, doing this straightforwardly is really annoying.
i cannot imagine alsamixer showing over 1400 bars.


> i guess i'll continue on trying to think of a different way to do
> this. but it seems to me that if the control API cannot support
> controls that need user data to read/write them, then we need to fix
> the control API.

i think adding new control types is a good solution in this case.
at least, we should not mix up these huge controls with normal ones,
to avoid to get GUIs confused.

my proposal is:

add two control types, MATRIX_INFO and MATRIX_ELEM.
MATRIX_INFO contains the size of elements, which is needed to
calculate the linear index from indices, so that the mapping is done
inside the alsa-lib.
some new (lib-)API functions will be provided to map the indices.
(alternatively, the matrix info can be integrated in
 snd_ctl_elem_info.  perhaps this is cleaner but the problem of
 listing remains - read ahead.)

the values are stored in MATRIX_ELEM controls.  each of them are
distinguished by different index values.
the notification will be sent to each MATRIX_ELEM, so the mechanism is
kept as well as before.

i'm not sure whether the matrix elements should be listed by
snd_ctl_elem_list().  usually it would be enough to know only the
matrix info, not the all values.
if we use MATRIX_INFO as a control, then listing only this would be
enough.  if we implement matrix info in snd_ctl_elem_info, then there
should be some workardound...


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> At Sun, 05 May 2002 21:32:12 -0400,
> Paul Davis wrote:
> >
> > >On Sun, 5 May 2002, Paul Davis wrote:
> > >
> > >> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
> > >> >byte per dimension).
> > >> >
> > >> >id.index = (source << 8) | destination;
> > >>
> > >> but there are 1400+ possible id's ...
> > >
> > >I agree with Abramo. We can eventually optimize code to handle such amount
> > >of controls.
> >
> > there's no reason to do that. if you're going to require that the user
> > merge two values into a single variable (as above), the user can put
> > the merged result in control->value.integer.value[0]. i just wanted a
> > way to avoid the user having to do this, because otherwise, it will be
> > impossible to ever build an automated GUI for the control (you'll
> > never be able to figure out how to generate the correct values from
> > the control API's description of the control).
> >
> > in addition, no automated GUI is possible with 1400+ controls given
> > the current API.
> >
> > in short, i really do not want to implement the H-DSP driver with this
> > kind of control over the matrix mixer. i raised this issue a month or
> > two ago, and there was (implicit) agreement then that it was silly to
> > represent all possible combinations with a 1:1 mapping between ALSA
> > controls and source/destination pairs.
> 
> the question is whether we do mapping on kernel or user space.
> Abramo's proposal means to do this on application side and it will
> need no change for API itself.
> 
> of course, doing this straightforwardly is really annoying.
> i cannot imagine alsamixer showing over 1400 bars.
> 
> > i guess i'll continue on trying to think of a different way to do
> > this. but it seems to me that if the control API cannot support
> > controls that need user data to read/write them, then we need to fix
> > the control API.
> 
> i think adding new control types is a good solution in this case.
> at least, we should not mix up these huge controls with normal ones,
> to avoid to get GUIs confused.
> 
> my proposal is:
> 
> add two control types, MATRIX_INFO and MATRIX_ELEM.
> MATRIX_INFO contains the size of elements, which is needed to
> calculate the linear index from indices, so that the mapping is done
> inside the alsa-lib.
> some new (lib-)API functions will be provided to map the indices.
> (alternatively, the matrix info can be integrated in
>  snd_ctl_elem_info.  perhaps this is cleaner but the problem of
>  listing remains - read ahead.)
> 
> the values are stored in MATRIX_ELEM controls.  each of them are
> distinguished by different index values.
> the notification will be sent to each MATRIX_ELEM, so the mechanism is
> kept as well as before.
> 
> i'm not sure whether the matrix elements should be listed by
> snd_ctl_elem_list().  usually it would be enough to know only the
> matrix info, not the all values.
> if we use MATRIX_INFO as a control, then listing only this would be
> enough.  if we implement matrix info in snd_ctl_elem_info, then there
> should be some workardound...

There is no need for MATRIX_ELEM type and however you'd need a _typed_
MATRIX_ELEM and this is a nonsense when already we have elements for
singleton controls.

Your question is: how to represent the info that a set of elements may
(should) be organized in a matrix?

We have already discussed that some time ago (about topology stuff,
etc., do you remember?) and we decided to keep out this mess from kernel
space.

We decided to have (if needed) card specific alsa-lib code to handle all
that.

If you ask me, I still think this this is indeed the right choice.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Takashi Iwai]

At Mon, 06 May 2002 14:19:14 +0200,
Abramo wrote:
> 
> Takashi Iwai wrote:
> > 
> > At Sun, 05 May 2002 21:32:12 -0400,
> > Paul Davis wrote:
> > >
> > > >On Sun, 5 May 2002, Paul Davis wrote:
> > > >
> > > >> >I suggest you to use the field index of struct sndrv_ctl_elem_id (one
> > > >> >byte per dimension).
> > > >> >
> > > >> >id.index = (source << 8) | destination;
> > > >>
> > > >> but there are 1400+ possible id's ...
> > > >
> > > >I agree with Abramo. We can eventually optimize code to handle such amount
> > > >of controls.
> > >
> > > there's no reason to do that. if you're going to require that the user
> > > merge two values into a single variable (as above), the user can put
> > > the merged result in control->value.integer.value[0]. i just wanted a
> > > way to avoid the user having to do this, because otherwise, it will be
> > > impossible to ever build an automated GUI for the control (you'll
> > > never be able to figure out how to generate the correct values from
> > > the control API's description of the control).
> > >
> > > in addition, no automated GUI is possible with 1400+ controls given
> > > the current API.
> > >
> > > in short, i really do not want to implement the H-DSP driver with this
> > > kind of control over the matrix mixer. i raised this issue a month or
> > > two ago, and there was (implicit) agreement then that it was silly to
> > > represent all possible combinations with a 1:1 mapping between ALSA
> > > controls and source/destination pairs.
> > 
> > the question is whether we do mapping on kernel or user space.
> > Abramo's proposal means to do this on application side and it will
> > need no change for API itself.
> > 
> > of course, doing this straightforwardly is really annoying.
> > i cannot imagine alsamixer showing over 1400 bars.
> > 
> > > i guess i'll continue on trying to think of a different way to do
> > > this. but it seems to me that if the control API cannot support
> > > controls that need user data to read/write them, then we need to fix
> > > the control API.
> > 
> > i think adding new control types is a good solution in this case.
> > at least, we should not mix up these huge controls with normal ones,
> > to avoid to get GUIs confused.
> > 
> > my proposal is:
> > 
> > add two control types, MATRIX_INFO and MATRIX_ELEM.
> > MATRIX_INFO contains the size of elements, which is needed to
> > calculate the linear index from indices, so that the mapping is done
> > inside the alsa-lib.
> > some new (lib-)API functions will be provided to map the indices.
> > (alternatively, the matrix info can be integrated in
> >  snd_ctl_elem_info.  perhaps this is cleaner but the problem of
> >  listing remains - read ahead.)
> > 
> > the values are stored in MATRIX_ELEM controls.  each of them are
> > distinguished by different index values.
> > the notification will be sent to each MATRIX_ELEM, so the mechanism is
> > kept as well as before.
> > 
> > i'm not sure whether the matrix elements should be listed by
> > snd_ctl_elem_list().  usually it would be enough to know only the
> > matrix info, not the all values.
> > if we use MATRIX_INFO as a control, then listing only this would be
> > enough.  if we implement matrix info in snd_ctl_elem_info, then there
> > should be some workardound...
> 
> There is no need for MATRIX_ELEM type and however you'd need a _typed_
> MATRIX_ELEM and this is a nonsense when already we have elements for
> singleton controls.
 
ok, the new element type is not necessary.  but something is needed to
tell it from others.

so far, we have no way to distinguish the matrix elements from
others.  imagine you implement all 1400+ elements as singletons.
what happens if you run alsamixer on that?
obviously showing all of them should be avoided.


> Your question is: how to represent the info that a set of elements may
> (should) be organized in a matrix?
> 
> We have already discussed that some time ago (about topology stuff,
> etc., do you remember?) and we decided to keep out this mess from kernel
> space.
 
yes.
please note that my proposal is based on the current implementation.
basically the matrix elements are mapped as 1:1 using a linear index
just like others.  i proposed MATRIX_ELEM not to mix up it with other
normal controls.  the mapping is done actually in alsa-lib.


> We decided to have (if needed) card specific alsa-lib code to handle all
> that.

ok, the problems are

- showing all matrix elements on GUI as normal elements is
  nonsense  -  there must be some flag to distinguish the matrix
  elements from others even if we implement the matrix on a linear
  array.

- we have no info to define the size of indices.
  without this info, the general mapping code cannot be implemented on
  the alsa-lib.


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> so far, we have no way to distinguish the matrix elements from
> others.  imagine you implement all 1400+ elements as singletons.
> what happens if you run alsamixer on that?
> obviously showing all of them should be avoided.

Already now alsamixer does not show all the controls. What's the
problem?

> 
> > Your question is: how to represent the info that a set of elements may
> > (should) be organized in a matrix?
> >
> > We have already discussed that some time ago (about topology stuff,
> > etc., do you remember?) and we decided to keep out this mess from kernel
> > space.
> 
> yes.
> please note that my proposal is based on the current implementation.
> basically the matrix elements are mapped as 1:1 using a linear index
> just like others.  i proposed MATRIX_ELEM not to mix up it with other
> normal controls.  the mapping is done actually in alsa-lib.
> 
> > We decided to have (if needed) card specific alsa-lib code to handle all
> > that.
> 
> ok, the problems are
> 
> - showing all matrix elements on GUI as normal elements is
>   nonsense  -  there must be some flag to distinguish the matrix
>   elements from others even if we implement the matrix on a linear
>   array.
> 
> - we have no info to define the size of indices.
>   without this info, the general mapping code cannot be implemented on
>   the alsa-lib.

Card specific code may solve all that easily.

We need to separate in our minds the _basic_ hardware access and
layout/display consideration. Kernel is for the former, libraries and
applications for the latter.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Takashi Iwai]

At Mon, 06 May 2002 21:11:09 +0200,
Abramo wrote:
> 
> Takashi Iwai wrote:
> > 
> > so far, we have no way to distinguish the matrix elements from
> > others.  imagine you implement all 1400+ elements as singletons.
> > what happens if you run alsamixer on that?
> > obviously showing all of them should be avoided.
> 
> Already now alsamixer does not show all the controls. What's the
> problem?

really..?  i thought alsamixer shows all normal controls except for
enum controls and ones with a volatile flag.  i must read the source
again...

> > 
> > > Your question is: how to represent the info that a set of elements may
> > > (should) be organized in a matrix?
> > >
> > > We have already discussed that some time ago (about topology stuff,
> > > etc., do you remember?) and we decided to keep out this mess from kernel
> > > space.
> > 
> > yes.
> > please note that my proposal is based on the current implementation.
> > basically the matrix elements are mapped as 1:1 using a linear index
> > just like others.  i proposed MATRIX_ELEM not to mix up it with other
> > normal controls.  the mapping is done actually in alsa-lib.
> > 
> > > We decided to have (if needed) card specific alsa-lib code to handle all
> > > that.
> > 
> > ok, the problems are
> > 
> > - showing all matrix elements on GUI as normal elements is
> >   nonsense  -  there must be some flag to distinguish the matrix
> >   elements from others even if we implement the matrix on a linear
> >   array.
> > 
> > - we have no info to define the size of indices.
> >   without this info, the general mapping code cannot be implemented on
> >   the alsa-lib.
> 
> Card specific code may solve all that easily.
 
that's true.
but user may start alsamixer (or what else) and get huge amount of
bars (i thought), which should be avoided.

> We need to separate in our minds the _basic_ hardware access and
> layout/display consideration. Kernel is for the former, libraries and
> applications for the latter.

i reconsidered this issue yesterday.
in this case, we need to take also the number of controls in the
kernel space into accout.  if we have an instance for each of 1400+
controls, there are really 1400+ mallocs, and we'll look for a control
by a linear search from them.
and most likely the hardware doesn't need them.
it will be a big drawback.

otoh, the indexed access as Paul's suggestion needs only one control.
the drawback of this method is, as Jaroslav pointed, the lack of
notification.  the notification can be done but we cannot know which
element is affected.


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Jaroslav Kysela]

On Tue, 7 May 2002, Takashi Iwai wrote:

> > Card specific code may solve all that easily.
>  
> that's true.
> but user may start alsamixer (or what else) and get huge amount of
> bars (i thought), which should be avoided.

We can avoid this in alsa-lib.

> > We need to separate in our minds the _basic_ hardware access and
> > layout/display consideration. Kernel is for the former, libraries and
> > applications for the latter.
> 
> i reconsidered this issue yesterday.
> in this case, we need to take also the number of controls in the
> kernel space into accout.  if we have an instance for each of 1400+
> controls, there are really 1400+ mallocs, and we'll look for a control
> by a linear search from them.
> and most likely the hardware doesn't need them.
> it will be a big drawback.

If someone has hardware with 1400+ controls, than memory allocation issue 
is out of question. I wrote that we can optimize current code - add some 
hash tables for faster lookups for example.

> otoh, the indexed access as Paul's suggestion needs only one control.
> the drawback of this method is, as Jaroslav pointed, the lack of
> notification.  the notification can be done but we cannot know which
> element is affected.

I think that it's much bigger drawback than allocation of some more 
kilobytes of memory.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Takashi Iwai]

At Tue, 7 May 2002 11:55:51 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 7 May 2002, Takashi Iwai wrote:
> 
> > > Card specific code may solve all that easily.
> >  
> > that's true.
> > but user may start alsamixer (or what else) and get huge amount of
> > bars (i thought), which should be avoided.
> 
> We can avoid this in alsa-lib.
 
yes.  i meant, anyway we need to implement a kind of workaround in the
general code of alsa-lib, not only as a card-specific plugin.


> > > We need to separate in our minds the _basic_ hardware access and
> > > layout/display consideration. Kernel is for the former, libraries and
> > > applications for the latter.
> > 
> > i reconsidered this issue yesterday.
> > in this case, we need to take also the number of controls in the
> > kernel space into accout.  if we have an instance for each of 1400+
> > controls, there are really 1400+ mallocs, and we'll look for a control
> > by a linear search from them.
> > and most likely the hardware doesn't need them.
> > it will be a big drawback.
> 
> If someone has hardware with 1400+ controls, than memory allocation issue 
> is out of question. I wrote that we can optimize current code - add some 
> hash tables for faster lookups for example.

well, about 200kB is not so big nowadays :)

i thought the hardware doesn't need allocate 1400 controls - the
controls are identical but have different indices.
in such a case, the indexed-access would be most straightforward.
no hash, no list.


> > otoh, the indexed access as Paul's suggestion needs only one control.
> > the drawback of this method is, as Jaroslav pointed, the lack of
> > notification.  the notification can be done but we cannot know which
> > element is affected.
> 
> I think that it's much bigger drawback than allocation of some more 
> kilobytes of memory.

hmm...


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Paul Davis]

>> If someone has hardware with 1400+ controls, than memory allocation issue 
>> is out of question. I wrote that we can optimize current code - add some 
>> hash tables for faster lookups for example.
>
>well, about 200kB is not so big nowadays :)
>
>i thought the hardware doesn't need allocate 1400 controls - the
>controls are identical but have different indices.
>in such a case, the indexed-access would be most straightforward.
>no hash, no list.

precisely. in fact, there are:

	   1456 mixer controls
	   52   RMS meters
	   80   peak meters

for the mixer controls, they form a matrix that is accessed by
index. for the meters, they form unidimensional arrays that are also
accessed by index.

i think any talk of allocating 1 control per "semantic control" is
crazy. its clear that these controls should be accessed as a matrix
type. they were designed by the h/w people as a matrix, and its been
ALSA's policy to have the kernel API mirror h/w designs and
capabilities. 

i can see no reason for not implementing the matrix type that takashi
suggested. its simple, its clean, it will work for notifications (you
just store the index in the information sent up to user space) and its
flexible for future hardware that use matrix controls.

i'm happy to do the implementation, but jaroslav and abramo seem
opposed to the idea.

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Abramo Bagnara]

Paul Davis wrote:
> 
> >> If someone has hardware with 1400+ controls, than memory allocation issue
> >> is out of question. I wrote that we can optimize current code - add some
> >> hash tables for faster lookups for example.
> >
> >well, about 200kB is not so big nowadays :)
> >
> >i thought the hardware doesn't need allocate 1400 controls - the
> >controls are identical but have different indices.
> >in such a case, the indexed-access would be most straightforward.
> >no hash, no list.
> 
> precisely. in fact, there are:
> 
>            1456 mixer controls
>            52   RMS meters
>            80   peak meters
> 
> for the mixer controls, they form a matrix that is accessed by
> index. for the meters, they form unidimensional arrays that are also
> accessed by index.
> 
> i think any talk of allocating 1 control per "semantic control" is
> crazy. its clear that these controls should be accessed as a matrix
> type. they were designed by the h/w people as a matrix, and its been
> ALSA's policy to have the kernel API mirror h/w designs and
> capabilities.

Sorry to say that, but I think this is a nonsense.

Many cards have element organized in register with an index (you might
say an "array"), but this is definitely not a reason to implement it in
a different way.

We have well designed control keys (id) and I don't see any reason to
change something that's perfectly suitable (without any compromise) for
the job.

We have the sane association one control / one value and just because
this card has many controls, you seems to wish to go toward a different
(IMO insane and confusing) solution.

Consider that independently from how you represent the data this card
will ever have many controls (i.e. many values to show/change).

I definitely don't see your point, sorry.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Paul Davis]

>We have well designed control keys (id) and I don't see any reason to
>change something that's perfectly suitable (without any compromise) for
>the job.

the implementation is not well designed for cases of 1500
controls. perhaps, as jaroslav says, this could be improved. but even
if that is done, the API forces the user application to do some
special encoding to generate the index that cannot be inferred from
the description provided by the API. an application that wants to
modify the gain for source S to destination D will have to know how to
encode S and D into the index - it cannot discover this from the API.

thats a lot worse than just a compromise if you ask me.

>We have the sane association one control / one value and just because
>this card has many controls, you seems to wish to go toward a different
>(IMO insane and confusing) solution.

IMHO, the 1:1 association is sane only when there are relatively small
numbers of controls. It doesn't make any sense to me to 

>Consider that independently from how you represent the data this card
>will ever have many controls (i.e. many values to show/change).

this isn't true. if we had a MATRIX element type, applications could
easily say

     "i don't display matrix elements"
     "i don't display matrix elements of dimensionality > 2"
     "i don't display matrix elements when the matrix is larger than N"

and so forth. the problem with the current system is that if anyone
makes the mistake of firing up a generic control API program, they
will see all 1500 controls. i'd like to see you explain that as "sane"
to the user.

>I definitely don't see your point, sorry.

are you claiming that you really designed the control API as it exists
now to handle situations with this many controls?

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Jaroslav Kysela]

On Tue, 7 May 2002, Paul Davis wrote:

> >We have well designed control keys (id) and I don't see any reason to
> >change something that's perfectly suitable (without any compromise) for
> >the job.
> 
> the implementation is not well designed for cases of 1500
> controls. perhaps, as jaroslav says, this could be improved. but even
> if that is done, the API forces the user application to do some
> special encoding to generate the index that cannot be inferred from
> the description provided by the API. an application that wants to
> modify the gain for source S to destination D will have to know how to
> encode S and D into the index - it cannot discover this from the API.
> 
> thats a lot worse than just a compromise if you ask me.

If we have agreement that multi-dimensional arrays uses 'unsigned int' 
from index divided to bits:

# of dimensions		bits
2			16
3			10
4			8
5			6

Then we have very clear way for applications to address source S and 
destination D. It doesn't break the current API in any way.

> >We have the sane association one control / one value and just because
> >this card has many controls, you seems to wish to go toward a different
> >(IMO insane and confusing) solution.
> 
> IMHO, the 1:1 association is sane only when there are relatively small
> numbers of controls. It doesn't make any sense to me to 

Sorry Paul, but I don't like optimizations against features. It's not
possible to add notification for values without addresses which you
propose without massive changes inside the midlevel kernel code for 
control API.

> >Consider that independently from how you represent the data this card
> >will ever have many controls (i.e. many values to show/change).
> 
> this isn't true. if we had a MATRIX element type, applications could
> easily say
> 
>      "i don't display matrix elements"
>      "i don't display matrix elements of dimensionality > 2"
>      "i don't display matrix elements when the matrix is larger than N"
> 
> and so forth. the problem with the current system is that if anyone
> makes the mistake of firing up a generic control API program, they
> will see all 1500 controls. i'd like to see you explain that as "sane"
> to the user.
> 
> >I definitely don't see your point, sorry.
> 
> are you claiming that you really designed the control API as it exists
> now to handle situations with this many controls?

Our API is not perfect, of course, but we can map every simple elements 
from kernel-space to user-space with it. You cannot say, that it's problem 
of the kernel<->user communication. Your objections are against visual 
representation which we can solve in the user space in more elegant ways.
There is a lot of work before us in alsa-lib to allow configurable simple 
mixer representations.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: how to define a 2-index control element?

[Takashi Iwai]

At Wed, 8 May 2002 09:52:48 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 7 May 2002, Paul Davis wrote:
> 
> > >We have well designed control keys (id) and I don't see any reason to
> > >change something that's perfectly suitable (without any compromise) for
> > >the job.
> > 
> > the implementation is not well designed for cases of 1500
> > controls. perhaps, as jaroslav says, this could be improved. but even
> > if that is done, the API forces the user application to do some
> > special encoding to generate the index that cannot be inferred from
> > the description provided by the API. an application that wants to
> > modify the gain for source S to destination D will have to know how to
> > encode S and D into the index - it cannot discover this from the API.
> > 
> > thats a lot worse than just a compromise if you ask me.
> 
> If we have agreement that multi-dimensional arrays uses 'unsigned int' 
> from index divided to bits:
> 
> # of dimensions		bits
> 2			16
> 3			10
> 4			8
> 5			6
> 
> Then we have very clear way for applications to address source S and 
> destination D. It doesn't break the current API in any way.
> 
> > >We have the sane association one control / one value and just because
> > >this card has many controls, you seems to wish to go toward a different
> > >(IMO insane and confusing) solution.
> > 
> > IMHO, the 1:1 association is sane only when there are relatively small
> > numbers of controls. It doesn't make any sense to me to 
> 
> Sorry Paul, but I don't like optimizations against features. It's not
> possible to add notification for values without addresses which you
> propose without massive changes inside the midlevel kernel code for 
> control API.
> 
> > >Consider that independently from how you represent the data this card
> > >will ever have many controls (i.e. many values to show/change).
> > 
> > this isn't true. if we had a MATRIX element type, applications could
> > easily say
> > 
> >      "i don't display matrix elements"
> >      "i don't display matrix elements of dimensionality > 2"
> >      "i don't display matrix elements when the matrix is larger than N"
> > 
> > and so forth. the problem with the current system is that if anyone
> > makes the mistake of firing up a generic control API program, they
> > will see all 1500 controls. i'd like to see you explain that as "sane"
> > to the user.
> > 
> > >I definitely don't see your point, sorry.
> > 
> > are you claiming that you really designed the control API as it exists
> > now to handle situations with this many controls?
> 
> Our API is not perfect, of course, but we can map every simple elements 
> from kernel-space to user-space with it. You cannot say, that it's problem 
> of the kernel<->user communication. Your objections are against visual 
> representation which we can solve in the user space in more elegant ways.
> There is a lot of work before us in alsa-lib to allow configurable simple 
> mixer representations.

the encoding/decoding of indices would be not serious problem.
as Jaroslav and Abramo suggested, we can linearize the multi-indices
well with that method.  this could be even hidden in alsa-lib's driver
plugin.


now let's focus on the different topic, which was originally proposed
by Paul - the implementation using indrect access.

looking at Paul's initial post again, i believe the idea is not bad
from the viewpoint of both kernel and user spaces.  it would bring
also only minimum changes.

let us compare the two implementations.


1. implementation using the existing simple control

the indices are linearized and used as the index of each control.

pro:
- kernel/lib api don't change at all

con:
- allocates 1400+ elements => needs optimization
- alsamixer (or more generally, alsa-lib) needs to be fixed, in order
  to avoid listing all of these controls up


2. implementation using the indirect access

it's implemented on the basis of simple integer control type, except
for that values on the struct are referred also when read.

pro:
- no big amount of allocations, one control for all
- it won't screw up alsamixer or other mixer

con:
- notification doesn't work properly on the current scheme
- alsamixer cannot access the mixer element directly ;)

the notification problem can be solved by allowing a driver-specific
tag (or private value, what-ever called) added in snd_ctl_event
struct.  the h-dsp driver will call notifier with this tag storing the
index value to be affected, and the application or the driver-plugin
of alsa-lib retrieves the index.

or alternatively, we may extend snd_ctl_elem_id itself, but i don't
think it's better.


apparently, on both implementations we need some changes over the
basis.  the former needs optimization and workaround in alsa-lib,
while the latter needs an extention to the api.
from these comparison, i feel it would be even easier to implement the
latter method.

well, the actual coding may be easier and faster than discussing too
much here :)


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net