At Tue, 7 Jul 2009 12:46:38 +0530, Harsha, Priya wrote:
> + .access = SNDRV_CTL_ELEM_ACCESS_READWRITE, > + .info = snd_intelmad_line_volume_info, > + .get = snd_intelmad_volume_get, > + .put = snd_intelmad_volume_set,
Can it have the dB information via TLV?
No. It actually differs across the 3 sound cards supported and it's not a direct TLV that can be used.
Then you'd set a static TLV entry after creating the ctl element instance, or return a TLV entry dynamically via the tlv callback.
Sorry I misunderstood. The value that is passed in min and max is in dB. For min and max values, it's a static dB value that I return. But when the volume adjustments need to be done, based on the value given by ALSA, I set the sound card registers to reflect that dB value.
The value to be set is always raw. That is, alsa-lib computes the raw value from the given dB value based on the TLV information (dB min/max), supposing the volume scale is logarithmic.
Isn't it the case for you?
Yes. I set the raw min and max values in db. And alsa-lib computes the volume value to be set (which is in between the min and max) and provides the same to the driver. The driver sets the corresponding sound card registers to reflect the same. In our case, the scale is not logarithmic in couple of sound cards and the vendor abstraction file would need to take care of the same to set the registers correctly.
Then it can't be exported as the existing TLV. The currently defined TLV types are logarithmic, linear, and combinations. I think it's better to fix the driver side to be logarithmic.
Takashi