A:

GNUsound should run on any GNU-based system with GNOME and a soundcard, but since the author develops GNUsound on a GNU/Linux system with Intel-based hardware, that is what is best supported. Ports to other systems or bug reports/patches relating to portability are always welcome.

A:

Ideally, a dual CPU machine with at least 1 GB of RAM and a multitrack audio card. I've found the Delta series cards from M-Audio/Midiman to work very well. On the software side, you might want to look into the various low-latency patches floating around for the Linux kernel.

A:

From version 0.7 onward, GNUsound can support audio drivers other than OSS. As of current writing, GNUsound supports both OSS and ALSA (versions 1.0.2 and greater). An experimental driver for JACK is also available.

A:

From version 0.7 onwards, GNUsound uses a modular file load/save architecture. Modules are provided for libaudiofile, libsndfile, LAME, FLAC and FFMPEG. See File format support for more information.

A:

There are a lot of reasons why this might happen. Generally it indicates that GNUsound didn't tend to the audio driver's needs quickly enough.

The problem with sound playback/recording is that sound cannot wait. If GNUsound cannot get fresh audio data to and from the soundcard quickly enough, you will hear pops and your recordings will contain garbage.

Standard computers running general purpose operating systems such as GNU/Linux have been designed to give good average performance across a wide variety of tasks. But audio applications don't care about average performance. They care about worst-case performance. Sadly, it is fairly hard for a general purpose system to make guarantees about worst-case performance, especially since doing so usually degrades overall performance.

The best way to minimize worst-case performance is to get a dual CPU machine and a good soundcard with good drivers. Also, building a low-latency kernel is a good idea. Andrew Morton maintains a bunch of low-latency patches for the 2.4 kernel series at http://www.zip.com.au/~akpm/linux/schedlat.html.

The 2.6 kernel includes its own set of measures to improve overall responsiveness and latency. You can also try another sound card or another driver (i.e. when you're using OSS drivers, try ALSA, and vice versa).

Some less intrusive measures that you can take are tuning the parameters in the Preferences->Play/Record tab and using a smaller zoom setting while playing and recording.

A:

Either because you've found a bug (please report it), or because you are running a Linux kernel that has ``memory overcommit'' enabled.

Memory overcommit is a Linux kernel feature that lets applications allocate more memory than is actually available. The idea behind this feature is that some applications allocate large amounts of memory "just in case", but never actually use it. Thus, memory overcommit allows you to run more applications than actually fit in your memory, provided the applications don't actually use the memory they've allocated. If they do, then the kernel terminates the application.

GNUsound needs enough memory (RAM + swap) to load a file into memory completely. GNUsound will try to recover gracefully from memory allocation failures, but sometimes it simply can't. In particular, you may have problems when using a kernel that has memory overcommit enabled. This may result in GNUsound being killed as it tries to load the file. To try and solve the problem, you can either increase the amount of memory (by adding RAM or swap), or you can disable memory overcommit by typing (as root):

$ echo 2 > /proc/sys/vm/overcommit_memory

A:

GNUsound needs memory to store the sound file itself, the clipboard buffer, and all undo buffers. Since sound files can be very big, this takes up a lot of memory. For that reason, many sound editors use a disk-based approach, where they use the disk to store some or all of the audio data. This allows them to edit and load files that don't fit into memory in their entirety. However, the disk-based approach requires a more complicated program design and in is almost always slower than the memory-based approach. That's incompatible with GNUsound's short-term goals, but future versions may provide support for a disk backing store.

A:

LADSPA stands for Linux Audio Developers Simple Plugin Architecture. This name is inaccurate, since neither is the functionality of LADSPA exclusively tied to the Linux kernel, nor are the developers of LADSPA related to Linux kernel development. The name LADSPA therefore furthers the confusion between the Linux kernel and the GNU/Linux system. As part of the GNU Project's effort to clear up this confusion, we refer to it as GLADSPA instead. For more information on why the name Linux does not fairly describe the GNU/Linux system, see http://www.gnu.org/gnu/gnu-linux-faq.html

A:

The name GNUsound is both a homage to and play on the GNU moniker. The official expansion of GNUsound is ``GNOME U sound editor'', where the "U" can stand for a number of mockingly depreciatory adjectives, such as unwarranted, undocumented, or Unix-incompatible.

As it turns out, some people didn't like the use of the GNU moniker, as GNUsound was not actually a GNU package. So GNUsound was proposed as a GNU package in December 2003, and officially became one in February 2004.