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