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.
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.