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: [EMAIL PROTECTED] _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
