Free audio software for linux

The Audio File Library provides a uniform and elegant API for accessing a variety of audio file formats, such as AIFF/AIFF-C, WAVE, NeXT/Sun .snd/.au, Berkeley/IRCAM/CARL Sound File, Audio Visual Research, Amiga IFF/8SVX, and NIST SPHERE. Supported compression formats are currently G.711 mu-law and A-law and IMA and MS ADPCM.

Key goals of the Audio File Library are file format transparency and data format transparency. The same calls for opening a file, accessing and manipulating audio metadata (e.g. sample rate, sample format, textual information, MIDI parameters), and reading/writing sample data will work with any supported audio file format. Likewise, the format of the audio data presented to the application need not be tied to the format of the data contained in the file.

The Audio File Library distributed under the GNU Library General Public License.

Cactus is just an audio file player. But it has some features that makes it different from other players.
There are music databases and there are players like xmms with a small and leightweight, skinable GUI.
Cactus combines these two types in one player! With Cactus you can read your music collection into a database, create a playlist by browsing/searching it and finally switch to player view(F2-Key).
Main features:
- Plattform independent
- Browse your music collection by artist, albums and titles
- Tiny lightweight player combined with a powerful database for organizing mp3-files
- Save and Load m3u Playlists
- Supports ID3v1(read/write) and ID3v2(read)
- Easy tagging of mp3-files
Enhancements:
- Some bugs concerning the playlist/tag-editing now fixed...

Nautilus-audio-convert is an extension of the Gnome desktop manager Nautilus. nautilus-audio-convert introduces contextual menus hen clicking on an audio file.

The new menus permit to convert the audio file into other audio formats.

Supported audio formats are:

- Microsoft ASF (input)
- Microsoft PCM Waves (input/output)
- Mpeg3 (input/output)
- Ogg Vorbis (input/output)

Bristol is an emulator for diverse existing synthesisers and organs. Currently, ten are implemented and a mixer is under development.
Bristol Audio software consists of an audio engine and an associated photo realistic graphical user interface called Brighton.
You may also want to chown/chmod bin/bristolengine to suid root, to allow it to use low latency scheduling. This will reduce audio underruns. You can also consider increasing bufsize and preload to reduce this effect, but this will lead to increased latency. Also, if you are using an SB Live! card with ALSA drivers you may need to configure a bufsize of 2048 (ie. 512 samples), which can be compensated for by reducing preload to 2 or 1.
Bristol will currently run 16 voices on a P-II 450, and this is the default voicecount. You can run any number of simultaneous synths - they all connect to the same engine, they will all run with the same polyphony since the MIDI voice structures allow for dynamic assignment of sounds to voices. You can run with split keyboard (no interface at the moment), layering of multiple synths on a single midi channel, etc. Some of the synths max out my P-II 450 CPU when there is a lot of MIDI activity, notably the DX and Explorer at 16 voices.
You can start different synths with different voicecounts, so you could have a 16 voice hammond, a monophonic minimoog, and a 5 voice prophet running at the same time - the GUI will negotiate the voice allocation requirements with the engine. The first synth you start will create the voice count. Subequent synths can have less than the initial value. If you start a monophonic synth first, you will only have one voice available at any time for all synths. If you layer synths you will reduce your polyphony since the engine will allocate multiple voices per keyed note.
Pressing the single letter q in the GUI will send a quit signal and the app will exit gracefully(?). When the last synths quits the engine will also exit. If you press the single letter p then libbrighton will dump a screenshot to /tmp/ .xpm (in XPM format only).
There is a LOT of debugging sent to stdout. You may want to consider adding redirects to /dev/null in the bin/startBristol script to get rid of it. When the final rev-1 is uploaded most of this will be taken out.
Enhancements:
- The graphics were cleaned up, some bugs were fixed, and work on a pair of Oberheim emulators was started.

Linux Audio Backstop project is a system for automated scheduling of audio recording and playback in a broadcast environment.
It includes features for controlling external audio switcher devices by means of serial and TCP/IP commands, as well as the ability to record and playback relay closures by means of the line of digital GPIO cards manufactured by MeasurementComputing.
The Linux Audio Backstop runs on the popular GNU/Linux operating system. It is freely available under the GNU General Public License.
Main features:
- Record and Playback up to four feeds simultaneously.
- Programmable from any web browser.
- Supports capture and playout of up to twenty-four discrete relay closures.
- Very lightweight and efficient - a Pentium 1 system is capable of hosting a complete system
- Runs on the rock-solid GNU/Linux operating system.
- Totally free and open -- No dongles, unlock codes, software keys or other arbitrary limitations.

Audio::ESD is a Perl extension for talking to the Enlightened Sound Daemon.

SYNOPSIS

use Audio::ESD;
my $stream = Audio::ESD->play_stream({ # these are the defaults
sample_rate => 16000,
channels => 1,
fallback => 0,
bits_sample => 16,
encoding => linear })
or die "Failed to open ESD stream: $!n";
print $stream $data; # etcetera

This module provides a Perl wrapper around the Enlightened Sound Daemons client library. Input, output, and monitoring streams are supported, as well as some (but not all) of the control functions. Samples are supported but untested.

Audio::DSP is a Perl interface to *NIX digital audio device.

SYNOPSIS

use Audio::DSP;

($buf, $chan, $fmt, $rate) = (4096, 1, 8, 8192);

$dsp = new Audio::DSP(buffer => $buf,
channels => $chan,
format => $fmt,
rate => $rate);

$seconds = 5;
$length = ($chan * $fmt * $rate * $seconds) / 8;

$dsp->init() || die $dsp->errstr();

# Record 5 seconds of sound
for (my $i = 0; $i < $length; $i += $buf) {
$dsp->read() || die $dsp->errstr();
}

# Play it back
for (;;) {
$dsp->write() || last;
}

$dsp->close();

Audio::DSP is built around the OSS (Open Sound System) API and allows perl to interface with a digital audio device. It provides, among other things, an initialization method which opens and handles ioctl messaging on the audio device file. Audio::DSP also provides some rudimentary methods for the storage and manipulation of audio data in memory.

In order to use Audio::DSP, youll need to have the necessary OSS drivers/libraries installed. OSS is available for many popular Unices, and a GPLed version (with which this extension was initially developed and tested) is distributed with with the Linux kernel.

Audio::MPEG is a Perl module for encoding and decoding of MPEG Audio (MP3).

SYNOPSIS

use Audio::MPEG;

Audio::MPEG is a Perl interface to the LAME and MAD MPEG audio Layers I, II, and III encoding and decoding libraries.

Rationale

I have been building a fairly extensive MP3 library, and decided to write some software to help manage the collection. Its turned out to be a rather cool piece of software (incidentally, I will be releasing it under the GPL shortly), with both a web and command line interface, good searching, integrated ripping, archive statistics, etc.

However, I also wanted to be able to stream audio, and verify the integrity of files in the archive. It is certainly possible to stream audio (even with re-encoding at a different bitrate) without resorting to writing interface glue like this module, but verification of the files was clumsy at best (e.g. scanning stdout/err for strings), and useless at worst.
Thus, Audio::MPEG was born.

LAME

This is arguably the best quality MPEG encoder available (certainly the best GPL encoder). Portions of the code have been optimized to take advantage of some of the advanced features for Intel/AMD processors, but even on non-optimized machines, such as the PowerPC, it performs quite well (faster than real-time on late 90s (and later) machines).

MAD

This is a relatively new MPEG decoding library. I chose it after struggling to clean up the MPEG decoding library included with LAME (which is based on Michael Hipps mpg123(1) implementation). In the end, I was very pleased with the results. MAD performs its decoding with an internal precision of 24 bits (pro-level quality) with fixed-point arithmetic. The code is very clean, and seems rock-solid. Although it may seem that it should be faster than the mpg123(1) library due to the use of fixed-point arithmetic, it is in fact about 60% or so of the speed (due to the higher resolution audio). However, the ease of coding against MAD, and the higher precision of the output more than makes up for the slower decoding.

Audio::MPEG can export the data at its highest precision for programs that wish to manipulate the data at the higher resolution.

Operating System Environment

I have only tested this on a Linux 2.4.x system so far, but I see no reason why it should not work on any Un*x variant. In fact, it may actually even work on a Windoze box (the underlying LAME and MAD libraries apparently compile somehow on them). I am doing no special magic with the interface, so presumably it will work under Windows. As you can probably tell, I dont really care if it does (Ill may start caring if M$ releases the source code to Windows under GPL, BSD, or Artistic licenses...). But, for you poor, misguided souls that insist upon running Windows, I expect that there should be little problem getting it to work.

Performance

You would think that with encoding/decoding audio, which is quite a compute-intensive task, Perl would be much slower than the equivalent pure C programs. Surprise... it is only about 3% slower (!) Even with the mechanism I use here (Perl->C->Perl for every frame, Perl 5.6.1 and Linux 2.4.4 (PowerPC 7500) performs just fantastic. So, the moral of this paragraph is to run your own performance tests, but theres no need to think of your own Perl encoder/decoder will be inferior to a pure C/C++ implementation. The only drawback is that, depending upon how much buffer space you use for reading, memory usage will be at least 3 times as much (eh... RAM is cheap...)