[alsa-devel] [PATCH - alsa-lib 2/3] tlv: Handle 'holes' in SND_CTL_TLVT_DB_RANGE array
tiwai at suse.de
Mon Jul 19 18:44:31 CEST 2010
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
> > 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.
More information about the Alsa-devel