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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
