
BUGS!
=====

monitoring with stalled data streams still eats cpu like the cookie monster
- tweak the sleep value for the select

<[D]espair> esd produces weird midbass static
- this one works:  cvs -z3 checkout -D "1998-10-10 ?23:00?" esound
- FIXED: don't bother with update, checkout the esound module again

Planned for 0.2.5:
==================

clean up esddsp.c for release with 0.2.5.

some semblance of documentation upgrade


Planned for 0.2.6:
==================

free samples when client closes

client request information on streams and samples currently in server

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.. :)

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

just allow setting of left/right volume. 

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.

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 );

esdfile.c - wrappers for caching and playing files via libaudiofile
factor out the file handling routines of esdplay into 
esd_play_steam_file(), and esd_cache_sample_file();

esd_rename_stream( int stream_id, char *name );

esd_player_t: add fields
	int left_vol_scale, right_vol_scale;

	vol = sample * vol_scale / 256;
same for samples

for Solaris: AUDIO_LINE_OUT, AUDIO_SPEAKER, AUDIO_HEADPHONE
for Linux: pick /dev/dsp2 if more than one card.  
Pass the device spec to esd_audio_open (?)

change audio device with esdctl? on the fly?


Planned for later:
================== 

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... :)

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.. 

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 ?;}

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

allow server to run mono.

kill_sample( int sample_id );

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

pitch adjust on samples?

playback samples at different rates?

endian swapping cleanup
