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