Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Ed Federmeyer <fedeedw@charlie.cns.iit.edu>
Newsgroups: scea.yaroze.programming.sound
Subject: Seqence data weirdness
Date: Sat, 26 Apr 1997 03:40:39 -0500
Organization: (no organization)
Lines: 30
Message-ID: <3361BF87.620D@charlie.cns.iit.edu>
Reply-To: fedeedw@charlie.cns.iit.edu
NNTP-Posting-Host: charlie.cns.iit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0C-GZone  (Win95; I)

I took the sound code from the walz demo, and put it into a separate
".c" file and got it working in the simple "hello world" program.

THEN, I thought, instead of hardcoding the addresses of where the VH,
VB, and SEQ data are, let me create arrays big enough to hold that data
and let the linker figure out where they should go.

Bleh, I ran into problems.

Eventually I tracked it down to needing to add (of all things) +1090
bytes or more to the size of the SEQ data array.  Even thought I
allocated 17341 bytes for the array (supposedly big enough to hold
GOGO.SEQ), it seemed to clobber the begining of the VB data array, which
just so happened to be right after it in memory.

Is there any reason why, if a file is X bytes in the CDROM directory,
(also the same number reported by CdSearchFile), that *more* than that
would be read?  Or does the CdReadFile function pad the data out to an
even buffer boundary?

Eventually, I'd like to malloc the buffer for the VB and VH data, since
it seems that once it is transferred to the sound buffer, it is no
longer needed in main memory, and the >400Kb VB data file will
eventually be a bit too much to have hanging around.  (Not a problem yet
for me, but one day...)  Am I right in assuming VB and VH data files are
not needed once they are transferred to sound memory?  Is the SEQ data
needed in main memory all the time?

If need be, I'll post a simple example.
EdF