From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: how to define a 2-index control element? Date: Wed, 08 May 2002 11:52:25 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20020508000005.EB5AC59D35D@kerberos.suse.cz> 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: Paul Davis , Abramo Bagnara , "alsa-devel@alsa-project.org" List-Id: alsa-devel@alsa-project.org At Wed, 8 May 2002 09:52:48 +0200 (CEST), Jaroslav wrote: > > On Tue, 7 May 2002, Paul Davis wrote: > > > >We have well designed control keys (id) and I don't see any reason to > > >change something that's perfectly suitable (without any compromise) for > > >the job. > > > > the implementation is not well designed for cases of 1500 > > controls. perhaps, as jaroslav says, this could be improved. but even > > if that is done, the API forces the user application to do some > > special encoding to generate the index that cannot be inferred from > > the description provided by the API. an application that wants to > > modify the gain for source S to destination D will have to know how to > > encode S and D into the index - it cannot discover this from the API. > > > > thats a lot worse than just a compromise if you ask me. > > If we have agreement that multi-dimensional arrays uses 'unsigned int' > from index divided to bits: > > # of dimensions bits > 2 16 > 3 10 > 4 8 > 5 6 > > Then we have very clear way for applications to address source S and > destination D. It doesn't break the current API in any way. > > > >We have the sane association one control / one value and just because > > >this card has many controls, you seems to wish to go toward a different > > >(IMO insane and confusing) solution. > > > > IMHO, the 1:1 association is sane only when there are relatively small > > numbers of controls. It doesn't make any sense to me to > > Sorry Paul, but I don't like optimizations against features. It's not > possible to add notification for values without addresses which you > propose without massive changes inside the midlevel kernel code for > control API. > > > >Consider that independently from how you represent the data this card > > >will ever have many controls (i.e. many values to show/change). > > > > this isn't true. if we had a MATRIX element type, applications could > > easily say > > > > "i don't display matrix elements" > > "i don't display matrix elements of dimensionality > 2" > > "i don't display matrix elements when the matrix is larger than N" > > > > and so forth. the problem with the current system is that if anyone > > makes the mistake of firing up a generic control API program, they > > will see all 1500 controls. i'd like to see you explain that as "sane" > > to the user. > > > > >I definitely don't see your point, sorry. > > > > are you claiming that you really designed the control API as it exists > > now to handle situations with this many controls? > > Our API is not perfect, of course, but we can map every simple elements > from kernel-space to user-space with it. You cannot say, that it's problem > of the kernel<->user communication. Your objections are against visual > representation which we can solve in the user space in more elegant ways. > There is a lot of work before us in alsa-lib to allow configurable simple > mixer representations. the encoding/decoding of indices would be not serious problem. as Jaroslav and Abramo suggested, we can linearize the multi-indices well with that method. this could be even hidden in alsa-lib's driver plugin. now let's focus on the different topic, which was originally proposed by Paul - the implementation using indrect access. looking at Paul's initial post again, i believe the idea is not bad from the viewpoint of both kernel and user spaces. it would bring also only minimum changes. let us compare the two implementations. 1. implementation using the existing simple control the indices are linearized and used as the index of each control. pro: - kernel/lib api don't change at all con: - allocates 1400+ elements => needs optimization - alsamixer (or more generally, alsa-lib) needs to be fixed, in order to avoid listing all of these controls up 2. implementation using the indirect access it's implemented on the basis of simple integer control type, except for that values on the struct are referred also when read. pro: - no big amount of allocations, one control for all - it won't screw up alsamixer or other mixer con: - notification doesn't work properly on the current scheme - alsamixer cannot access the mixer element directly ;) the notification problem can be solved by allowing a driver-specific tag (or private value, what-ever called) added in snd_ctl_event struct. the h-dsp driver will call notifier with this tag storing the index value to be affected, and the application or the driver-plugin of alsa-lib retrieves the index. or alternatively, we may extend snd_ctl_elem_id itself, but i don't think it's better. apparently, on both implementations we need some changes over the basis. the former needs optimization and workaround in alsa-lib, while the latter needs an extention to the api. from these comparison, i feel it would be even easier to implement the latter method. well, the actual coding may be easier and faster than discussing too much here :) Takashi _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net