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

[Abramo Bagnara <abramo@alsa-project.org>]

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