		   wavplay-1.0.tar.gz
		Mon Apr 14 20:49:33 1997
		  Warren W. Gay VE3WWG

Let's talk about bugs (I know its a icky topic but..)

In  general,  wavplay and wavrec themselves should be relatively free of
bugs  now,  unless you can find some more (by all means report them, but
see at bottom of file).

The  xltwavplay  program  however, is brand spanking new, and where I've
spent  a  large  portion of my time lately.  Its design also impacts the
server.c module that participates from the wavplay executable as it runs
in  server  mode (note that the server.c code inside wavplay is not used
when  wavplay  is invoked from the shell).

In  a  nutshell,  xltwavplay  and  the  server.c module added to wavplay
represents a fair bit of work, and require lots of people pounding on it
to  ferret  out  any remaining bugs.  So while there may be a few little
bugs  in  xltwavplay,  I  think  that  you'll  find  it quite usable and
conveniant to use.  You should _NOT_ see any core files and nasties like
that (exception noted below with LessTif).

If  you're using real MOTIF linked to xltwavplay, you should be a pretty
happy  camper.  If not, then drop me a line explaining (not COMplaining)
the problem (I don't have it myself, or I would test it).

===================
IF YOU USE LESSTIF:
===================

There  is  still more work needed by the LessTif group on List Boxes and
File  Selection  Dialogs (at least in my experience using LessTif 0.77).
If  you  can,  use a  LessTif  version  newer  than  0.77  as it becomes
available. Things are being fixed every month.

Currently  list boxes blank out at various times, in response to various
events.  While  this is annoying, you will find that the items are still
actually there, and  can be  made  visible  individually by  clicking on
those  lines where you think they might be. Occaisionally the list boxes
does lose items, but this doesn't happen often.

File  selection  dialogs  suffer from the same problem (because I assume
they also employ these same list boxes). The resizing policy seems a bit
extreme at times also, when changing directories etc. with the filter.

CORE FILES:

Occaisionally,  the  File  Selection dialogs will cause a core dump when
you mess with the filter button. It is my hope that the LessTif team can
use this software to  expose  these problems, and hopefully fix them for
us.

When  reporting  problems  to  the LessTif mailing list, please be kind,
since they  are  working  hard  on their own volunteered time to provide
this software which we can all enjoy.


===============================
SOUND GLITCHES AND LIMITATIONS:
===============================

Please  keep  in mind that we are attempting to do real time things when
playing/recording  wav files  on  a  non  realtime platform! If you have
heavy  CPU load and/or disk activity, then please don't report the sound
glitches  as bugs when its just because your CPU cannot keep up with the
sampling rate. If your system swaps a lot, you'll also have gaps.

I  have  found through experience however, that my humble 486DX at 33Mhz
can  play wav  files  just fine most of the time (remember that /dev/dsp
has sizable buffers to take up the slack).  Sometimes however, the first
time  a  wav file is played, extra shared library links get "snapped" (I
think), which  may introduce  long  enough delays such that the /dev/dsp
device driver does not get samples fast enough (it starves). Most of the
time, successive plays occur without a glitch.

If  you're  making  a serious recording, keep the system activity to the
minimum  that you can. I would further suggest that you play a small wav
file  before  making  your  first  recording.  This  should take care of
snapping any share libraries etc.

======================================
MY PAUSE BUTTON SEEMS TO LOSE SAMPLES:
======================================

If  you  PLAY  a  wav file and then press PAUSE in xltwavplay, expect to
lose a bunch of samples.  The reason is fairly simple: serveral KB worth
of  samples  are  shoved  into the /dev/dsp buffers to keep it well fed,
since if it gets starved you'll hear glitches in the sound (and we don't
like  that). To  stop  almost  immediately,  much of that queued data is
dumped.  So  when you  resume  with  PLAY, you'll often notice that some
sound  was  lost.  At some future date, if this ever becomes enough of a
priority, I can probably compensate for this.  But at this moment I have
bigger plans for its future.

=======================
I WANT TO REPORT A BUG:
=======================

Fine.  Be my guest.  But pulease give me something to work with when you
submit the  problem! If  I had a nickle for every message I got like "It
wouldn't  compile.  Can you help me?", then I'd be running a Pentium Pro
by now. :)

If  it doesn't compile, get the error message text and forward _THAT_ to
me. If you're  using X, the use the mouse to copy the text of the screen
and pasted that into the message to me.  If you're not using X, then try
something like this:

	$ make 2>&1 | tee errors.out

This  allows  you  to  see  the  messages  in real time, and capture the
messages to file errors.out as well.  Include the contents of errors.out
in your message please.

Also please describe something about your system:

	LINUX Kernel Version? (important)
	CPU type?
	Amount of memory?
	Video card (if you think it has a bearing)
	What sound card type?
	
Please describe your C compiler tools:

	GCC --version
	Version of the C libraries (if you can tell me this)


These  are  at  least  good  places  to  start  when reporting a bug.  I
currently  prefer  my  email  sent to me at wwg@ica.net, since I pick up
that  mail every  day.  However, use bx249@freenet.toronto.on.ca if I've
moved on,  since  that  is my  backup account that I plan to keep for at
least 2 more years.

Please   distinguish   between  programs  wavplay  and  xltwavplay  when
reporting  problems.   Finally,  if  the  program  has  trouble  with  a
particular file's data, then please be prepared to send me a sample that
I can test with.

If  wavplay  won't  play  or  record at all, then make sure you have the
sound  card  installed  correctly.  Ask  yourself,  does  this work from
DOS/Windoze ok? If not, then perhaps that's a place to start.  If that's
ruled  out,  then make sure your kernel has sound driver support.  Newer
kernels may require you to LOAD the module to support the sound driver.

Last,  but  not  least, some of you out there are running very old LINUX
kernels.  While I have nothing against vintage code, I must suggest that
the  sound card  support has changed a lot since 0.xx versions of LINUX.
Please  consider upgrading  ASAP  if you're running something older than
1.2.13.

Thanks! Enjoy.


Send correspondance to:
 
 	Warren W. Gay VE3WWG
 	5536 Montevideo Road #17
	Mississauga, Ontario L5N 2P4
 
Email:
	wwg@ica.net			(current ISP of the month :-) )
	bx249@freenet.toronto.on.ca	(fallback account)

End BUGS.
