[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:01:10 +0100,
Mark Brown wrote:
> 
> On Mon, Jul 19, 2010 at 05:51:27PM +0200, Takashi Iwai wrote:
> > Peter Ujfalusi wrote:
> 
> > > If user asks for 1dB the snd_tlv_convert_from_dB will not find
> > > the raw value, since the 1dB is not part of either range.
> 
> > In the case above, can't you set like
> 
> > 	TLV_DB_RANGE_HEAD(2),
> > 	0, 2, TLV_DB_SCALE_ITEM(-1000, 500, 0),
> > 	2, 4, TLV_DB_SCALE_ITEM(0, 200, 0)
> 
> > ??
> 
> So, this came from a review comment from me in response to a patch doing
> just that.  The issue I had was that this definition of overlapping
> ranges really feels like the kernel is bodging around limitations of the
> userspace library - the library is already trying to find the best match
> among the actual dB values available, it seems silly that it requires
> the kernel to provide patches between the ranges.  It's moderately
> painful, especially if you have a bunch of values that aren't very well
> joined together in the hardware.

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.

Note that TLV_DB_RANGE isn't necessarily incremental.  The current
algorithm is straight to pick up the first matching one.  So, any
overlap can be handled in the definition itself.  (In the case of
point-overlap, it shouldn't be a big problem, anyway.)
The proposed fix for alsa-lib assumes that the incremental ranges,
thus it's also not reliable in 100%.

If kernel changes would become too messy, then yes, we can reconsider
fixing this only in alsa-lib, though.


thanks,

Takashi