Hello All, Sorry about the silence, I was away from the office for couple of weeks. Anyway here is the original patch modified to suit the bluez coding conventions. There might still be something (I'm quite bad with these issues...) I also added Siarhei's rounding stuff to the filter tables. Good point Siarhei! Concerning Brad's comments I think the calculation of tables should now be quite clear. There are comments on the tables how to produce them in Octave and the filtering function is very basic fixed point Q15 calculation. I agree that including the original float values to the code would probably be a good idea. Then we could just use some macro at compile time to modify them to suitable Q format and original values would always be there to be viewed and compared to. I would still be careful about the optimization of the filtering, so that we don't obfuscate the code too much. The filter and cosine table are quite small so we should consider how much we save in computation. Anyway if the savings are significant let's just add them there. br, Jaska Uimonen On Wed, 2008-12-17 at 00:37 +0200, Siarhei Siamashka wrote: > On Monday 15 December 2008 17:16:58 ext Brad Midgley wrote: > > I like your idea of using a macro with the original floating point > > tables, as long as we know it is done at compile time, not runtime :) > > What about something like this modification to Jaska's patch? It contains > floating point constants wrapped into a macro. > > This version is using 16-bit multiplications only (additional natural change > would be just to convert 'sbc_encoder_state->' to int16_t because it does not > need to be int32_t), which is good for performance for the platforms with fast > 16-bit integer multiplication. But it is also flexible enough to be changed to > use 32x32->64 multiplications just by replacing FIXED_A and FIXED_T types > to int64_t and int32_t respectively (for better precision or experiments with > conformance testing). > > > > Can anybody try to remember/explain what transformations were applied to > > > the existing fixed point implementation? > > > > it was done by several people and the only record we have is in cvs. > > (part of it is in the old btsco project's cvs) > > Regarding the code optimizations. Looking at the tables, It can be seen that > 'cos_table_fixed_8[0+hop]' is always equal to 'cos_table_fixed_8[8+hop]'. > The same is true for 'cos_table_fixed_8[1+hop]' and 'cos_table_fixed_8[7+hop]' > So it is possible to join 't1[0] + t1[8]', 't1[1]+ t1[7]' and the other such > pairs, effectively halving the number of counters. This looks very much like > the optimization that was applied to the current fixed point code :) > > But now it would be very interesting to see if the conformance tests pass > rate is better with the new filtering function. > > > Best regards, > Siarhei Siamashka
Attachment:
0001-New-function-and-tables-for-8-band-fixed-point-analy.patch
Description: application/mbox
