[FFmpeg-devel] Fixpoint FFT optimization, with MDCT and IMDCT wrappers for audio optimization

[Marc Hoffman]

On 7/30/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Jul 30, 2007 at 04:09:52PM -0400, Marc Hoffman wrote:
> [...]
> > > > > if you want to optimize the code please first do highlevel
> > > optimizations
> > > > > that is change the code to a split radix fft
> > > > > then _while_ very carefully testing the accuracy on _real_ sound
> > > perform
> > > > > low level optimizations
> > > >
> > > >
> > > > I guess I'm missing something here.  Why are you so bent on this split
> > > radix
> > > > thing?
> > >
> > > common sense?
> > > first you choose the most efficient algorithm then AFTER THAT you go and
> > > optimize it, what you do is like optimizing a bubble sort while refusing
> > > to
> > > use a quicksort ...
> > >
> > > i agreed to your original proposal of doing optimizations later i do not
> > > agree to low level optimizations of an inefficient FFT
> >
> >
> > And which algorithm is the most efficient?
>
> who knows ...
> but shouldnt the question rather be which is the most efficient which you
> would be willing to implement? ;)

I can do either, but this is the set I think we need to start our
activities in the world of fixedpoint audio.

>
> split radix is fairly simple ...
>
Agreed however...

I will do it if it makes sense right now I don't see it being the most
efficient. Lets get through the basic acceptance and when you and I
decide to move forward we can talk about more efficient mechanisms for
general machines.  (I'm not going anywhere so even if you accept this
we can change it in the future).

The split radix is not the most efficient way to do things on the
BlackFin machine.  It has to do with all the extra pointer stuff you
need to maintain.  On other machines this is more efficient.  Not to
go into this too much anyways I agreed earlier to implement this for
us (ffmpeg-devel) and I will just not right now.  I really want to see
if I/we can get one audio codec to work in fixEDpoint and achieve high
quality I think this is what you/we really care about anyways.

I will fix up the fft-test which I completely agree needs some house
keeping and then repost probably as is on the fft kernels until we get
further down the development path.

I would like to keep the semantics in the FFT's the way they are with
the scaling normalization done in this particular way.  For all of the
machine (I know of) which would have to do this type of operation the
normalization is 100% correct.

The confusing one is the FFT16 which does this special extra re-norm
in the loop.  I think it generated the confusion which caused you/us
to go down the path of why not just shift by 16 in the loop.  I could
remove this FFT completely for now if its a problem Michael.  Its a
low quality transform as you pointed out, however it does have
reasonable performance and might fair well in certain situations.

Does this sound reasonable?

Marc