[vorbis] mdct.c pointer to array conversion

[Govind Kharbanda]

Keith Wright wrote:
> 
> > From: Govind Kharbanda <govind.kharbanda at sli-institute.ac.uk>
> >
> 
> > I'm attempting to convert all the pointers to arrays [in] the
> > mdct_backward function so it can be partitioned off for a hardware
> > implementation.
> >
> <snip function headers>
>
> I don't understand the point of this.  In C, arrays and pointer are
> (except for syntax) the same thing.

That is true.  The pointer is used to pass over the start address of a
block of memory from which the mdct_backward function can read
successive data.  The hardware MDCT core does not have access to the
memory of the host PC but only to its own SRAM.  Therefore, the data
will have to be copied across.  Therefore, mdct_backward will have to
pass over the arguments explicitly.

I guess I will run into problems here if passing over DATA_TYPE in[]
does not pass over the whole array but just the start address.  In this
case I'll have to rethink my strategy so that the hardware has all the
data copied over and not just start addresses.

<snip lots of useful stuff>

> So the real problem is when to transfer the trig tables to
> the coprocessor.  It appears to me that these are constant
> tables that are set up in 'block.c' by two calls to 'mdct_init'.

Yes I noticed this too a couple of hours ago, trig is essentially a
lookup table set up during the mdct initialisation.  I'd been so tied up
with mdct_backward that I hadn't looked at the rest of mdct.c!  As they
are constant lookup tables it also explains why I was getting
*(init->trig)=1.00000 when I was running sample ogg files as this would
be the first value of the trig table.  Just a thought.... the lookup
tables are being supplied with every Ogg window???

N.B. I'm confused between 'frame' and 'window'.  When I read init->n =
2048 is this window size or frame size?

> If this is indeed the case then you could put both of them in
> the coprocessor during initialization and refer to them simply
> as '0' and '1' when calling
> 
>   #if COPROCESSOR
>   #  define MDCT_LOOKUP_N int
>   #else
>   #  define MDCT_LOOKUP_N mdct_lookup *
>   #endif
>   void mdct_backward(MDCT_LOOKUP_N init, DATA_TYPE *in, DATA_TYPE *out)
> 
> Then the call (in 'mapping0.c') changes from
> 
>     mdct_backward(b->transform[vb->W][0],pcm,pcm);
> 
> to simply
> 
>     mdct_backward(vb->W,pcm,pcm);
> 

Using #defines seems a really good idea: it keeps everything portable. 
I'll have to digest your comments a bit further though until I
completely buy your argument why the "mdct_lookup *" can be replaced
with an "int".  OK, the trig data has been set up separately but don't
we have to transfer over n, log2n, bitrev, scale etc..

> Warning!  I am a dangerous ignoramus.  The above random thoughts
> are not backed by a deep understanding of Vorbis.  The Xiphites
> probably have reasons for the way they did this---of which I
> know nothing at all.

Thanks for the disclaimer.  I am an even more dangerous and ignorant
hardware developer, at least for the next 7 weeks anyhow.

Gov

-- 
Govind S Kharbanda                Institute for System Level Integration
MSc Course Rep.                        Alba Campus, Livingston, EH54 7EG
http://www.sli-institute.ac.uk/~gk/                    Tel: 01506 469340
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.