make the reading/mixing process a separate thread from the 
client protocol parsing thread.

command line parameter for the server's fragment value

One other nice feature of
the BeOS streaming model is that you can choose where your application
should be positioned in the stream (beginning | end | don't care).
Could be done with some extra parameters to esd_play_stream()..?

mmap the data into the sound card? -- Linux only

[raster!raster@trode.redhat.com] actuyally dump like 1k oir
whatever - tell soudncard to start at the first 1kb
-white readihg this (the soudncard) write the 2nd kb -
then the 3rd etc... u just have to keep in step witht
the card and a little ahead of it... but only just enuf
to minimise lag.

it does need better logic for the "monitoring only" case.  right now
it just writes a zeroed buffer to the sound card, so as to force
a block on the data write, thus freeing the cpu for other processes.
intelligent blocking needs to be done, probably by merging the 
get_new_clients and poll_client_request logic into the same 
blocking select() call.

it's also rather fiddly wiht cpu usage spikes.. 

oh.. one last thing i thought of.. it'd be great to be able to add a
"final filter" client that gets all sound like the monitor.. but can
send it back "filtered" (andy way it pleases) and the filtered sound
gets played.. so this filter can add echo, reverb, vibrato, filter
frequencies, do phase shifts etc...

also beng able to request info on all connected clients (numebr,
sampling rate etc. etc.) and modify that clients volume or mute that
client..kill it.. etc.. so in effect a window manager for sound could
be written.. :)

for samples we need:
message for sample kill

oh.. volume control on samples and streams would be nice.. :)

just allow setting of left/right volume. allow a "volume envelope"
sample to be paired witht the sample optionally - perhaps at a lower
sampling rate and maybe 8 or 4 bits.. this sould in addition to "set lr
volume for smapl/stream now" functions... :)

play sample, loop sample, end sample:
int play_tri_sample( start, loop, end ) { 
        play(start); loop(loop); return end;
}
later: 
int finish_tri_sample( end ) { play(end); return ?;}

Volume and left/right volume would be on a per-play basis, then?
play_sample_pan( int sample_id, int left_volume, int right_volume );

so that would be something like (format determined by sample uploaded):
modulate_sample( int play_sample, int modulation_sample );

straighten out exactly what gets printed to the screen when and how
esd_debug(); ???

allow server to run at sample rates lower than 44.1kHz, or mono, or 
8 bit, or any combination of the above.  probably need function 
pointers in mix.c to do this well:
  mix_funcs[MAX] = { mix_to_format, mix_from_format, clip_format, ... };
and update according to specs.

kill_sample

add a queue of requests to the sample clients, and watch for kills?

pitch adjust on samples?

playback samples at different rates?

esd segfautls if u free a sample BEFORE its finished playing 
and u can't know when its finished.. :)
