Hi, I'm waiting for comments for the series against alsa-lib regarding this issue... On Monday 19 July 2010 11:51:41 ext Mark Brown wrote: > On Mon, Jul 19, 2010 at 08:57:05AM +0300, Peter Ujfalusi wrote: > > On Friday 16 July 2010 15:33:25 ext Mark Brown wrote: > > > Isn't this going to get messy when the increments don't line up so that > > > it's easy to overlap the start of one range with the beginning of the > > > next? > > > > Well, I assume however writes the driver knows how to build up a lookup > > table which is consistent, so I don't really see a problem. > > The problem I see is if the hardware step sizes result in discontinuties > in the scale so you can't easily join the top end of one set of values > with the bottom end of another you're pretty stuck - joining the ranges > up will only work if they can be made to overlap which isn't always > going to be the case. Yeah, and the tpa6130a2 is even worst than most of the things that I have ever seen: http://focus.ti.com/lit/ds/symlink/tpa6130a2.pdf, page 20 Basically there are no continuous ranges at all (sometimes it feels, that the steps are chosen via lottery). > For example, something like: > > 1: 0 > 2: 2 > 3: 4 > 4: 5 > 5: 7 > 6: 9 > > (a bit artificial but you get the idea) is going to be a bit tricky. I see, but I still don't see problem with this: non-overlapping (A): static const unsigned int nonoverlapping_tlv[] = { TLV_DB_RANGE_HEAD(2), 1, 3, TLV_DB_SCALE_ITEM(0, 200, 0), 4, 6, TLV_DB_SCALE_ITEM(500, 200, 0), }; overlapping (B): static const unsigned int overlapping_tlv[] = { TLV_DB_RANGE_HEAD(3), 1, 3, TLV_DB_SCALE_ITEM(0, 200, 0), /* at raw 3 the dB is 4 */ 3, 4, TLV_DB_SCALE_ITEM(400, 100, 0), /* at raw 4 the dB is 5 */ 4, 6, TLV_DB_SCALE_ITEM(500, 200, 0), }; B covers all ranges, with 3 sub-range. A covers the ranges, which has 2dB steps, and leaves a hole for the 1dB step between raw 3, and 4. > > I'll post patches against alsa-lib to fix the _DB_RANGE handling. It will > > take some time to understand, and fix the code + testing it. > > Thanks. No problem. With the patches I have sent for alsa-lib both A and B style of array going to be handled correctly. If you have time, can you take a look at them? Thanks, Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
