On Mon, 29 May 2006, Takashi Iwai wrote: > At Mon, 29 May 2006 16:12:34 +0100, > James Courtier-Dutton wrote: > > > > Jaroslav Kysela wrote: > > > On Mon, 29 May 2006, Takashi Iwai wrote: > > > > > >> What we'll get by this compression is only the reduction of ioctl > > >> size. But, these ioctls are called not so often and no time-critical > > >> task. > > > > > > Nope. I'm talking about saving code in alsa-lib. Having a special case in > > > alsa-lib for all hints is not really good. If you can store all necessary > > > ranges to 32-bit value (which is allocated anyway) is a win. Of course, > > > all mechanisms as James proposed will not be changed. I see only one > > > problem why my proposal is not acceptable - we must store also the > > > identifier type to the 32-bit value in the kernel side. Also, having both > > > min and max values is not necessary (it can be evaluated from step). > > > > > I don't understand where you think you are making a win with these > > 32-bit values? None of the information is stored in alsa-lib after the > > function has returned to the user app. It is all temporary use. > > Maybe cached values to avoid too frequent ioctls? > > But, still it won't save so much memory at all, given that we have at > most 100 controls with volumes... Sorry, I was looking to the proposed patch very quickly so my ideas were based on old implementation which is #if 0 #endifed for alsa-lib (there was only one 32-bit hint value specifying the dB expression). Jaroslav ----- Jaroslav Kysela <perex@xxxxxxx> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
