bugs

使用在嵌入式linux平台或pc机上的wave文件录制和播放软件

$Id: BUGS,v 1.2 1999/12/04 00:01:20 wwg Exp $
		   wavplay-1.4.tar.gz
                Fri Dec  3 23:26:20 1999
		  Warren W. Gay VE3WWG
                 mailto:[e-mail]

There are still issues in wavplay regarding certain legal, but unusually
formatted wav  files  that  it  does not handle correctly. 

================
COMMON PITFALLS:
================

Many emails I get are related to the following user errors:

	1. The user never installed the release patches. At this time
	   there are no patches for release 1.4, but if you do
	   experience problems, please check to see if patches
	   have been released by the time you read this. You can
           also check http://members.home.net/ve3wwg for pointers
           to software and patches.

	2. If you are installing the X component xltwavplay, which
	   is entirely optional, then make sure that you've first
	   installed X, its libraries and its include files. Second,
	   make sure you have MOTIF or LessTif installed correctly.
	   These are major sources of user problems.

	3. If you are compiling xltwavplay, then make sure you go
	   over the Makefile. There are a number of places where
	   directories and linking options may need to change based
	   upon your X/MOTIF/LessTif installation.

	4. Keep in mind, that if you are using LessTif, that the
	   LessTif effort is still in progress. LessTif is getting
	   pretty cool these days (at least if you like X/MOTIF). 
	   However, there may still be issues that are not related
	   to this software.

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

The  wavplay-1.0  release  was  compiled  without  any  of the real time
benefits that can be had under LINUX.  At the suggestion of Dirk Pfau at
[e-mail], I  have since  added  a  call  to sched_setscheduler()  to
incorporate   LINUX   real   time  scheduling,  provided  you  configure
SCHED_PRIORITY  in  the Makefile  (by default  this is configured with a
real time priority of 9).

The  sched_setscheduler()  call  should  work  quite  well in giving the
wavplay  server  (only)  the necessary  system  priority  to  play sound
samples  without  gaps  or  glitches.  If  a  busy  system  still causes
playing/recording to  glitch then  you  may  want to use a higher valued
SCHED_PRIORITY value (assuming you have other real time tasks running on
your system). This real time scheduling, should improve your recordings.

============
SETUID ROOT:
============

In order to call sched_setscheduler() with a SCHED_PRIORITY of more than
0 (to be useful), you must have root privileges. This is because you are
gaining  improved scheduling privileges this way. Running any program as
root has its security drawbacks.  I have endeavoured to only run as root
long   enough    to    process    the   command   line   options,   call
sched_setscheduler() and  then  switch back to the natural userid.  This
allows  the  program  to call sched_setscheduler(), but prevents it from
being  able  to  overwrite any file (record mode), or to access any file
(play  mode)  that it  might  otherwise be  able to  do, if the  program
continued to run as root.

If  running a program setuid root bothers you, or presents too much of a
security  risk,  then  comment  out  the  SCHED_PRIORITY  entry  in  the
Makefile.

As a further precaution, you will be required to do a 'make setuid_root'
after  the  initial  install,  if  you HAVE choosen to use the real time
scheduling feature. By  doing  so  you assume all of the risk associated
with  any  possible  security breach of running wavplay as a setuid root
program.

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

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.

=========================
YOU WANT TO REPORT A BUG:
=========================

Please  give  me  something to work with when you submit the problem.  A
number of  people tell  me  "its broken" and expect me to read minds.  I
don't read minds -- just ask my wife ;-)

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 paste that into the message for me.

Runtime  errors  from xltwavplay can be had by starting it from an xterm
session, since many messages go to stderr.

For catching compile errors, try:

	$ make 2>&1 | tee errors.out

To force a remake, try:

	$ make clobber all 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 to me please.

Make sure you have sound support compiled into your kernel.

Also please describe something about your system:

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

	GCC --version
	uname -a  (lists some system info like kernel release)

These  are  at  least  good  places  to  start  when reporting a bug.

Anyway,  for  now,  send all correspondance to [e-mail].  You can
also  check  the  web page at members.home.net/ve3wwg If all else fails,
look  for   an  updated   LSM   file  entry  on  a  ftp  site  near  you
(sunsite.unc.edu being my favourite).

Please  distinguish  between  the  programs  wavplay and xltwavplay when
reporting  problems. Note  also, if the problem is with only certain wav
files,  or wav  files  from  a certain  tool,  then please remember that
wavplay does  not  properly process all legal variations of wav files at
this time.

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 and its
configured  OK.  Newer  kernels  may require  you  to LOAD the module to
support  the sound  driver.  Make  sure  your  special  device  file  is
available and has permissions (usually its /dev/dsp).

Send correspondance to:
 
 	Warren W. Gay VE3WWG
	[e-mail]
	http://members.home.net/ve3wwg

End BUGS.