>> 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

Reply via email to