🚀 go-pugleaf

Thanks, there are some useful infoZ in there.

I was thinking along the lines of a continuous FIFO ring buffer and
monitoring the buffer pointer's position, so there is continuous
output to the sound card, and so I know where the timebase of the
buffer is so when the buffer can accept new data I can put it in
there.

Will using repeated calls to the Borland sound playing functions to
send a buffer segment indroduce audible clicks?    Are you suggesting
sending the data to the soundcard one byte at a time, and is this the
most commonly used method?

The sounds would be in internal and external resources, all in the
same bitrate / frequency / format.  Since they will be reasonable in
size I will load them all into RAM on loading / startup, maybe
addressing them as 

WAVSOUND sounds[250];
(The WAV data lengths will be different)

using a struct for WAVSOUND
#define struct  WAVSOUND {
LONG soundlength;
SOUND * sounddata;
};
SOUND will be a SHORT PTR pointing to the start of the sound data for
each sound, initialized to the address of the sound resource.

At any time at most I might be in the process of sending as many as 50
or 55 different waveforms to the buffer out of the 150.  (Say 30
crickets chirping at 30 different sound levels, 10 frogs singing
(sounds like crickets almost) at 10 different volume levels, and three
frogs croaking at 3 different levels and maybe a couple of nighthawks
calling or mabe a roll of thunder in the distance).   I need to keep
track of all the data pointers and introduce new streams and end those
that are finished.

What you suggest, it sounds like it will be faster than the soundcard
can handle so I will have to wait for the sound card to be ready,
which is what I want of course.

What is the function to check whether the card is ready to accept new
data?