Hopefully most of unix/compiler variant issues should be handled by configure
process. Thus porting issues should reduce (for UNIX-ish machines at least)
to writing the audio driver.

The interface to the driver is defined in hplay.h.
There are three routines:

extern int audio_init PROTO((int argc, char *argv[]));

 Do what ever is necessary to initialize audio.
 You can process any command line arguments to influence the 
 behaviour. Use getargs() function to make this easy.
 Where it make sense copy options from other drivers e.g. -r for 
 sample rate.

 This routine should also define the global variable samp_rate
 to define sample rate to the core synth.

 Sample rates in 8 - 12kHz range work best due to as yet unresolved
 problems with some of the digital filters.

extern void audio_play PROTO((int n, short *data));

 Send a block of 'n' 16 bit signed linear samples to the 
 audio device. If your device requires uLaw samples (US telephone standard)
 then l2u.h defines routines which may help (example is Sun driver).

extern void audio_term PROTO((void));
 Close down audio device, probably waiting for buffer(s) to empty.

To test your driver (which should be called xxxxplay.c where xxxx describes
the system/hardware), link it to hplay.c, and "make".

The brave/experienced  might like to obtain and install GNU autoconf-2.0 (or
latter?) and the GNU m4 it needs (m4-1.3 or latter), and try and get the new
driver auto configured.
 
When you have written your driver please contact me (nik@tiuk.ti.com)
if you are willing to let others use it. Please let me know the output of
config.guess  script to assist in merging into autoconf. 

------------------------------------------------------------------------

Perfomance issues.

For best speed in parwave.c all arthmetic is done in "float",
but with strict IEEE-754 compliance turned off.
This is fastest because in general for modern RISC processors
(e.g. SPARCs or at least some of them ...)

  - There is no integer multiply hardware
  - There IS floating point multiply hardware
  - Floating point multiply hardware cannot handle "double" in one pass.
  - Some of IEEE-754 options (e.g. denormals) are handled via software traps.

This may be less true of x86/68xxx machines...

The computations in parwave.c should dominate the cpu requirements
of the other levels.