From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: how to define a 2-index control element? Date: Tue, 07 May 2002 12:34:48 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Jaroslav Kysela Cc: Abramo Bagnara , Paul Davis , "alsa-devel@alsa-project.org" List-Id: alsa-devel@alsa-project.org At Tue, 7 May 2002 11:55:51 +0200 (CEST), Jaroslav wrote: > > On Tue, 7 May 2002, Takashi Iwai wrote: > > > > Card specific code may solve all that easily. > > > > that's true. > > but user may start alsamixer (or what else) and get huge amount of > > bars (i thought), which should be avoided. > > We can avoid this in alsa-lib. yes. i meant, anyway we need to implement a kind of workaround in the general code of alsa-lib, not only as a card-specific plugin. > > > We need to separate in our minds the _basic_ hardware access and > > > layout/display consideration. Kernel is for the former, libraries and > > > applications for the latter. > > > > i reconsidered this issue yesterday. > > in this case, we need to take also the number of controls in the > > kernel space into accout. if we have an instance for each of 1400+ > > controls, there are really 1400+ mallocs, and we'll look for a control > > by a linear search from them. > > and most likely the hardware doesn't need them. > > it will be a big drawback. > > 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. > > otoh, the indexed access as Paul's suggestion needs only one control. > > the drawback of this method is, as Jaroslav pointed, the lack of > > notification. the notification can be done but we cannot know which > > element is affected. > > I think that it's much bigger drawback than allocation of some more > kilobytes of memory. hmm... Takashi _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net