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

[Takashi Iwai <tiwai@suse.de>]

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