At Mon, 29 May 2006 16:17:40 +0200 (CEST), Jaroslav Kysela wrote: > > On Mon, 29 May 2006, Jaroslav Kysela wrote: > > > On Mon, 29 May 2006, Takashi Iwai wrote: > > > > > Also, a bit more sensible names are preferred for new stuff. > > > "misc" sounds too ambiguous to me, and "info2" is... > > > > Perhaps 'desc' like description or 'extra' is more appropriate. > > > > Also, I'm not sure, if hint is the right behaviour. Probably, the better > > way is to create a new identifier and ecapsulate min, max and step values > > into 32-bit word, so we won't eat much memory and the information for > > alsa-lib will be more abstract for your case. Of course, some hardware can > > have non-continuous dB scale so special expressions must be in alsa-lib. > > Replying myself: > > For example, 32-bits can be separated to: > > 12-bits manimal value (0-4095) => 0.05dB => -154.75dB - 50dB > 12-bits maximal value (0-4095) => 0.05dB => -50dB - 154.75dB > 8-bits step value (0-255) => 0.05dB => 0-12.75dB > > It will satisfy nicely requirements for both drivers and has plenty space > to store more wide ranges. > > Also, handling of first value as mute can be specified as a new > indentifier in the TLV tree. Well, the principal question is whether we need such a hack at all. We don't need to store the values for _each_ element in the driver side. Most of elements have the same dB range, so the record is shared. For USB and HD-audio, the records are dynamically created, anyway. 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. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
