Re: dB gain

[James Courtier-Dutton <James@superbug.co.uk>]

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