[vorbis] mdct.c pointer to array conversion

[Keith Wright]

> From: Govind Kharbanda <govind.kharbanda at sli-institute.ac.uk>
> 
> Keith Wright wrote:
> > 
> > I don't understand the point of this.  In C, arrays and pointer are
> > (except for syntax) the same thing.
> 
> That is true.  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.
> 
> 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.

The 'if' is superfluous here.  That's the semantics of C.  I was afraid
I might be insulting by explaining C, but that does seem to be part of
your problem, and I am very much more sure about C than any part of
Vorbis.  If you want to copy an array you must write a loop to do
it, or use a library functions like 'memcpy' or 'strcpy'.

> 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.

Yes, at least the data to be Fourier transformed must be copied
explicitly---the tables maybe not.

> Just a thought.... the lookup tables are being supplied with every
> Ogg window???

There seem to be only two tables, for the two window sizes, and it
passes a pointer to one or the other, but this causes no copying when
done in C on one processor.

To make it efficient with a coprocessor I think one would want to
set up both tables in the coprocessor just once at the beginning
and pass only an indication of which one to use, which might as
well be a small integer.

> 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..

I think the whole 'lookup' table has only two version, including
all those parts.  But I am not sure, so check it out before you
believe me.

I always put changes in #define unless I am very sure.  It helps
portability, and when things go wrong I can compile out the changes
and assure myself that the problem is not due to something totally
unrelated that has gotten broken.

Now that I understand your problem a little better though, I
withdraw the suggestion to change types of the arguments to
'mdct_backward'.  Better to leave the interface alone, but
replace the body of the procedure with one that sets up
communication with the coprocessor, copies the necessary data,
and fires off the computation.

Eventually you will want to overlap the computation of the
coprocessor with settiing up the next block of data, but
I would want to see it working with one block at a time
before messing with this next level of complication.


-- 
     -- Keith Wright  <kwright at free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---
--- >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.