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. I don't have min and max values. I have: int32_t db_per_devision; /* Use db per devision * 100 */ int32_t db_offset; /* Use dB offset * 100. This identifies the 0dB point */ int32_t db_mute; /* The value, before conversion, that is equivalent to MUTE */ Now, not all controls have a mute at the minimum value. If the minimum % is a mute, then the db_mute == this minimum % value. If the minimum % is not mute, then the db_mute equals a value outside the % range, so the comparison to db_mute is always false for that control. The current type implemented is: For simple dB*100 = (X * db_per_devision) - db_offset with a special case for detecting the mute value. More complex conversion functions will have a different equation, and therefore possibly a different amount of parameters, so one would just implement a new type, and parse as many parameters from it as we need. James _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
