Re: [RFC/PATCH] sbc: new filtering function for 8 band fixed point encoding

[Jaska Uimonen <jaska.uimonen@nokia.com>]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

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 #2: 0001-New-function-and-tables-for-8-band-fixed-point-analy.patch --]
[-- Type: application/mbox, Size: 7221 bytes --]