home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Source Code 1992 March
/
Source_Code_CD-ROM_Walnut_Creek_March_1992.iso
/
usenet
/
altsrcs
/
3
/
3593
/
NOTES
< prev
next >
Wrap
Text File
|
1991-07-07
|
3KB
|
85 lines
The internals of AUX are a little odd: there are separate
read/write modules for each sample format, and their coding
is quasi object-oriented.
AUX includes skeleton handler files to assist you in supporting
new formats. The full skeleton driver, skel.c, helps you write drivers
for a new format which has data structures. The simple skeleton drivers
help you write a new driver for raw (headerless) formats, or
for formats which just have a simple header followed by raw data.
Most sound sample formats are fairly simple: they are just a string
of bytes or words and are presumed to be sampled at a known data rate.
The Sparcstation is an example of this: .AU files are headerless,
logarithmically encoded (u-law) bytes, sampled at 8192 hertz.
The file au.c implements this by setting the input or output parameters
to these specifications and invokes the raw handler.
The 'tests' file shows how to specify the .AU parameters from the
command line.
Handler spec:
A handler is responsible for translating between sound sample files
and an internal buffer. The internal buffer is store in signed longs
with a fixed sampling rate. The handler operates from two data structures:
a format structure, and a private structure.
The format structure contains a list of control parameters for
the sample: sampling rate, data size (bytes, words, floats, etc.),
style (unsigned, signed, logarithmic), number of sound channels.
It also contains other state information: whether the sample file
needs to be byte-swapped, whether fseek() will work, its suffix,
its file stream pointer, its handler pointer, and the private
structure for the handler.
The private handler is just a preallocated data array for the handler
to use however it wishes. It should have a defined data structure
and cast the array to that structure. See voc.c for the use of
a private data area. Voc.c has to track the number of samples it
writes and when finishing, seek back to the beginning of the file
and write it out.
A handler has 6 routines:
startread
Set up the format parameters, or read in
a data header, or do what needs to be done.
read
Given a buffer and a length:
read up to that many samples,
transform them into signed long integers,
and copy them into the buffer.
Return the number of samples actually read.
stopread
Do what needs to be done.
startwrite
Set up the format parameters, or write out
a data header, or do what needs to be done.
write
Given a buffer and a length:
copy that many samples out of the buffer,
convert them from signed longs to the appropriate
data, and write them to the file.
If it can't write out all the samples,
fail.
stopwrite
Fix up any file header, or do what needs to be done.
Comments:
Theoretically, handlers can be used to manipulate several files
inside one program. Multi-sample files, for example the download
for a sampling keyboard, can be handled cleanly with this feature.
Portability problems:
Many computers don't supply arithmetic shifting, so do multiplies
instead of << and >> .
Do all arithmetic bit-shifting conversions one stage at a time.
I've had too many problems with "obviously clean" combinations.
In general, don't worry about "efficiency". The aux.c base translator
is disk-bound on any machine (other than a 8088 PC with an SMD disk
controller). Just comment your code and make sure it's clean
and simple.