On Wed, 2 Apr 2003, Abramo Bagnara wrote:
> Jaroslav Kysela ha scritto:
> >
> > I feel we are still thinking in a different way. The separating of
> > volatile data is only access and memory optimization. The code in the
> > control interface uses still linear lookups. Note that there is no
> > restriction to use this "multi" element for matrix only. Then address in
>
> I realized that.
>
> > matrix is always mapped to linear one. If you want a gap inside matrix,
> > then set the INACTIVE flag to the access field (volatile data). It's quite
>
> It's not inactive, it does not exists.
>
> > complicated to describe such incomplete matrixes in a generic way. Note
>
> ? Why complicated?
>
> What about snd_ctl_add_index(ctl, index) (then you can use data tables,
> loops, wrappers, etc.)
It breaks the linearity and makes lookups much slower.
> > that the whole matrix is still represented as one multi element inside the
> > kernel space (except that volatile data are separate for each value inside
> > matrix).
>
> This is true only for non sparse matrix.
>
> Ortogonally to that, IMO the increasing numbers of controls in modern
> professional hardware justify the choice of hash table access to
> controls (try to imagine a 26 channel hardware level meter that need to
> be polled 50 times per second).
I don't mind if I have only one lookup for this set of controls as present
in the current code. Actually, the most of cards have around tenths of
controls (including HDSP driver after ported to use multi controls) so
adding a hash lookup is not a big win in my eyes. Yes, we can do it in
future, when we will have hundreds or thousands controls per card.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
