[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization

[Marc Hoffman]

On 7/15/07, Benjamin Larsson <banan at ludd.ltu.se> wrote:
>
> Marc Hoffman wrote:
> > On 7/15/07, Benjamin Larsson <banan at ludd.ltu.se> wrote:
> >> Marc Hoffman wrote:
> >>> This patch changes the way the data flows by introducing a vec_t data
> >>> type which is just unsigned char. This way we can abstract the low
> >>> level data type itself keeping the logic the same.  I'm using a char
> >>> type so we can walk through the data this is not possible with voids
> >>> to my knowledge. I have chosen to use vec_t so that we can easily
> >>> locate the vectors which represent the input and output signals of the
> >>> system.
> >> Ok, I don't know if this is the best way to do it, but I'll assume it
> is
> >> for now.
> >>


Ok now that we have decided on 32bit representation. I guess we need to
eliminate the f_sample_size and just let the assumption that float is always
32 bits.  BTW is this always true?  I think for the class of machines we are
talking about this is the case but we might want to use this on other
machines as well.  I will adjust the code to remove q->f_sample_size and use
sizeof (vec_t), where vec_t will be uint32_t if that makes it simpler.
Please make a better suggestion if you have a better idea.



>>> I will then add a set of overloaded primitives to the existing
> >>> structure that handle the lowlevel stuff like quantization, decouple,
> >>> satruate, interpolate, and imlt etc that needs to know if your working
> >>> with float or shorts.  I want to keep all the logic the same so I will
> >>> also introduce a fixpoint fft which I'm in the process of developing
> >>> under the ffmpeg license as GPL code.
> >> No chance for a LGPL license ? And if you need a reference fp fft to
> >> look at use this:
> >
> >
> >
> > LGPL thats what I meant .
>
> Ok, nice. And if you have the time implement a split radix version with
> 2, 3, 4 and 5 radixes. There will be a need for doing fft's with a size
> of 640 when the siren codec is added to ffmpeg.



Great! we would implement something like a 128 point followed by a 5 point
to get a 640 point system.  If thats what you mean by a fix radix.

[...]
>
> > I guess you might be correct. Initially I was thinking we might be able
> to
> > use 16-bit ints to represent the signal and not 32-bits.  I'm still not
> sure
> > if the implementation requires the higher precision to be maintained
> does
> > anyone know if the algorithm requires the 24bits?
> >
>
> Well what I meant was that I don't think 16 bits is enough for the
> transform step to keep a good enough precision. So if 32 bits is needed
> in the transform step then why not use 32bits in all the calculations
> for simplicity.


You are correct, we have to have 32bits of precision. Do you think a 32x16
would work where the phase factors are 16 bits and the samples are 32 bit?
Computationally this is really the best for these low power low complexity
machines. I wrote both versions 32x32 and 32x16 we can use either and
measure the performance.


Marc