BUGS

			GLAME - KNOWN BUGS
			==================

The following list contains a summary of all known bugs/caveats/missing
features you may run into and some help how to survive in these cases.

If you experience GLAME behaving in strange ways other than those listed
below, please don't hesitate to submit a bug report, either via

* The Bugs web page at SourceForge, 
  http://sourceforge.net/tracker/?atid=101627&group_id=1627&func=browse

* Your distribution's bug tracking system (like the Debian BTS, for example),

* The GLAME user support mailing list <glame-users@lists.sourceforge.net>.

When reporting a bug, in addition to a detailed description please include 
the exact version of GLAME you are using, and the operation system, version,
and distribution you are running.

Summary of known bugs and misfeatures in GLAME
----------------------------------------------

- Its not a good idea to have the glame swapfile reside on a non-local
  disk (like in your NFS mounted home) because of performace limitations.
  As the default location set by the gui is ~/.glameswap you should change
  that to something more reasonable (Settings/Preferences...) if your
  home is not local.

- Even with low buffer size GLAME is not really a real-time capable
  synthesizer (though you're able to use GLAME as an effect generator
  while playing guitar). Try using decent sound hardware and ALSA.

- There exist some broken audio hardware or broken drivers - to name a few
  we stomped over: the ISA soundblaster cards dont seem to be good enough
  to allow recording in GLAME, the via8cxxx_driver in the linux kernel has
  problems recording mono (supposed to be fixed with recent driver versions).

- If the online-help does not work you either need to install gnome-help
  or put the path to the glame .info documentation into your gnome-helps
  documentation path.

- There seems to be a rather large memleak either in the fft plugin or in
  the libfftw used - but its only temporary during the plugin running.

- BSD may have not sufficient threads support. Simple test for this is to
  issue
  cglame> (test-latency 5)
  within cglame. If it returns to the command line everything is fine -
  if it hangs forever thread support is broken (try installing the
  linuxthreads package in this case).

- The pipe_in/pipe_out plugins (and the derived read-mp3.scm filter)
  crash on some systems due to either pthread limitations or pthread
  or libc or kernel bugs (we need to trace this) - if you're lucky, it
  might work for you (it does for me on a debian potato system with
  kernel 2.4.[34]). If it doesnt work, it will take GLAME with it and
  you might not notice that.

- If glame panics this could be a glame bug (as usually panics are "this
  should not happen" things) - we're interested in reports of such
  occasions, especially if its reproducable. Please include a description
  on how to reproduce it and the output from glame or cglame (preferrably
  compiled with --enable-debug). In case the panicing location is inside
  the swapfile code there may be an external source corrupting the swapfile
  - just restart glame in this case and it will try to recover (can you
  say fsck?).
 
07-15-01 Modifications made in the swapfile GUI are
  not reflected by existing waveedit views. To work around this re-open
  affected waveedit views.

07-15-01 Waveedit views dont support horizontally sequenced waves. The
  waveview will refuse to open. Copy the affected group (or do not) and
  use "flatten" from inside the swapfile GUI to merge those waves.

07-15-01 You cant play horizontally sequenced waves because there is no
  place from the GUI where you can issue the play command.

07-15-01 Closing windows while there is action going on may lead to
  segfaults. Don't do that.

07-15-01 Not all (nearly none) parameters of filternetworks show realtime
  response on modification while a network is running.