[alsa-devel] [PATCH - alsa-lib 2/3] tlv: Handle 'holes' in SND_CTL_TLVT_DB_RANGE array

[Takashi Iwai]

At Mon, 19 Jul 2010 17:24:17 +0100,
Mark Brown wrote:
> 
> On Mon, Jul 19, 2010 at 06:11:30PM +0200, Takashi Iwai wrote:
> 
> > Well, one remaining question is how to handle if the hardware has
> > really no value in a certain range (a hole).  Fixing in alsa-lib is a
> > sort of workaround, but it doesn't sound right, especially if the
> > range info can be provided correctly in the source.
> 
> I guess it depends on what you're thinking of for an inexact match - if
> we're doing inexact matches within the range we're already saying that
> we're not giving 100% accuracy (and remember that some hardware has very
> coarse control).  It seems wrong that we'd fail to match with a slighy
> inaccuracy when the requested value happens to be just outside the range
> but accept any old accuracy level from coarse grained steps.

The guess work isn't always trivial.  If the hardware switches the
curve between log and linear over a hole, which should be taken for a
value in the hole?  Whne TLV is given for the hole, at least it's a
good hint.

> > If kernel changes would become too messy, then yes, we can reconsider
> > fixing this only in alsa-lib, though.
> 
> Personally I'd rather the kernel just provided a mapping between control
> values and dB scales and then the application layer can decide what it
> thinks an appropriate match is.  Decisions about how accurate a match is
> needed seem very policy like and therefore userspaceish and it seems
> wrong to be coding the data tables in the kernel in a way that works
> around the particular match algorithm in the application layer.

User space can check the correctness always by checking the reverse
conversion between dB <-> value again.


thanks,

Takashi