Modules

This section briefly describes the various modules that come with GNUsound. Some of these modules (such as some of the file and audio driver modules) are "faceless", in that they extend GNUsound's functionality without providing a means to interact with them.

Those modules that can be interacted with are available via the Tools menu. Most of them need an active selection to operate on, and can be further controlled using envelopes.

This module implements support for the LADSPA plugin architecture.

You must install some GLADSPA plugins to use this module, these can be obtained from http://www.ladspa.org. Before starting GNUsound make sure the LADSPA_PATH environment variable points to the location where your plugins are installed. If the LADSPA_PATH is not defined then GNUsound will search /usr/local/lib/ladspa for plugins.

The interface for this module consists of a window that is split in two halves: the left half contains the available plugins, and the right half contains the parameters for the selected plugin.

When the list of plugins is active, you can press a key to jump to the first plugin whose name starts with that letter.

The right half of the window has sliders to set the parameters for the plugin. You can use the Env1 and Env2 buttons to assign a parameter to the corresponding envelope. The envelope modifies the parameter value in the following way: if the envelope value is 0, then the parameter value is the parameter value set by the user. If the envelope value is between 0 and 1, then the parameter value is between the user selected parameter value and the maximum parameter value. Finally if the envelope value is between 0 and -1, then the parameter value is between the user selected parameter value and the minimum parameter value.

An envelope assigned to a GLADSPA parameter does not change that parameter every sample; rather the signal is processed in blocks and the envelope value applies to an entire block. The size of these blocks can be changed in the configuration file (the ladspa_segment_time parameter). The default value for this parameter is 0.01 seconds.

This module changes the sampling rate of the selected audio. Depending on whether you have libsamplerate installed it offers one or more methods of doing so, with varying quality/speed tradeoffs. The primary envelope controls the rate.

From version 0.7 onwards, GNUsound uses a modular playback/record architecture. This makes it easier to support different audio APIs.

The Open Sound System is an obsolescent audio API for Unix. It comes in a Free variant, which is a part of the Linux kernel, and a commercial variant marketed by 4Front Technologies. The commercial variant is better in some respects than the Free version and supports some very high quality audio cards. OSS/Free has been deprecated since Linux kernel version 2.6 in favor of ALSA (Advanced Linux Sound Architecture).

The OSS API is rather sparse. Trying to do anything beyond simple playback and record with OSS/Free is basically impossible due to the varying quality of drivers and hardware and the poorly specced API. On the other hand, OSS is widely available and easy to use for both developers and users.

The OSS driver has undergone a lot of testing. So this is a good choice if you don't need any of the advanced facilities offered by ALSA.

From version 0.7 onwards, GNUsound uses a modular file load/save architecture. This makes it much easier to add support for new file formats.

Which file drivers are available depends on your system configuration at build time. If you want to take advantage of the improved file format support you will need to install the software mentioned below prior to building and installing GNUsound.

When loading a file, GNUsound tries to autodetect the file type by having each driver probe the file in turn, until one of the drivers recognizes it.

This is not a waterproof strategy: it's not always possible to determine the file type with 100% certainty. In particular the LAME and FFmpeg drivers can sometimes misidentify files. This can lead to garbage being read or even crashes.

To minimize the chances of this happening, the order in which the file is probed by the drivers is important. They need to be ordered in such a way that the driver with the highest probability of getting confused gets to probe last.

The default probe order was determined through some experimentation to give the best results, but if necessary it can be changed through the file.drivers.probe_order preference.