home *** CD-ROM | disk | FTP | other *** search
- 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.
-