oreilly.comSafari Books Online.Conferences.


Linux Audio Plug-Ins: A Look Into LADSPA

by Dave Phillips

Plugging in...

As users, we choose specific applications because their features suit our purposes. As we become more familiar with a program, we want more features added to it, and of course we want it to run faster and smoother. Developers want to serve the needs of end-users, but increasing the internal complexity of an application is not necessarily a good thing, and programmers and users alike recognize the undesirability of feature creep and code bloat.

Nevertheless, we all want more cool and useful features in our software, giving rise to a dilemma: How do we balance the number and complexity of features against the complexity and manageability of the larger-scale program design?

A flexible architecture that allows plug-ins is an elegant solution to this problem, presenting the end-user with a mechanism to control at least some aspects of a program's feature set while giving program developers the opportunity to focus their energy toward creating flexible core engines and program frameworks. In addition, designers of plug-ins can work on developing their processing algorithms without the distraction of resolving interface or operating system dependencies. Everyone wins with plug-ins.

What is a plug-in anyway?

A plug-in is a software module that adds new functions or extensions to a host application, without the need to recompile the program. The plug-in functions are stored within a shared object file (*.so in Linux, *.dll in Windows) that may contain one or several plug-ins. The application provides the entry points to dock an object, and the new functions are immediately available. The user accesses the plug-in as a normal part of the host's interface.

Linux users are perhaps most familiar with the plug-in architectures for the GIMP image processor and for the XMMS media player. These applications provide developers with simple plug-in programming frameworks, while providing users with transparent interfaces for managing and applying third-party extensions.

GIMP and XMMS are wonderful programs and their plug-in collections are impressive. However, the plug-ins designed for these programs will work only with their intended applications and not others. Obviously a more universal plug-in architecture would be a very good thing: Developers could be freed from rewriting their code to accommodate different plug-in specifications; various applications could share the same resources; and users could build libraries of plug-ins to use with their favorite plug-in-friendly applications.

Such a solution already exists in the Mac and Windows audio software worlds in the form of the VST plug-in architecture. VST has been widely accepted as the de facto standard for audio plug-ins, with support coming from almost every major audio software house. Numerous collections of VST plug-ins are available over the Internet. Some are wonderful; some are not so wonderful. Some cost money while others are free. But almost all of these plug-ins will only work in Windows or Mac OS.

The special benefits of sound software plug-ins include interesting extensions such as digital signal processing (reverberation, chorusing and flanging effects, amplitude and ring modulation, dynamics processing, etc.), software synthesis (waveform and wavetable generators), mixing and balancing modules, and even composition-oriented utilities such as sequencers and random-number generators.

Several Linux audio applications support plug-ins; however, like GIMP and XMMS, their plug-in architectures are application-specific and do not provide a generalized plug-in API (application program interface) for Linux audio software. In the early stages of LADSPA development, some members of the LAD group contacted the Steinberg company in hopes of porting the VST architecture to Linux; alas, they got no joy.

Steinberg's license does not permit the redistribution of modified versions of its freely available VST SDK (a situation that could be neatly resolved if they adopted the GPL); however, a greater problem is that most VST plug-ins rely either on the native interface or libvstgui, a graphic interface library that has not been implemented in any of the popular GUI toolkits for Linux.

Even this reliance could be overcome with a new Linux implementation of libvstgui, and although the documentation for libvstgui fully specifies the API and even includes some source, this is a substantial programming effort that nobody has been willing to undertake to date. As a result, despite its theoretical portability, the VST API remains tied to the Windows and Mac interfaces, leaving Linux developers with a need for a simple standard for writing audio plug-ins. Enter LADSPA -- the Linux Audio Developer's Simple Plug-in API.

What's LADSPA ?

The original incentive for LADSPA development evolved from discussions that took place on the LAD (Linux Audio Developers) mailing list from late 1999 to early 2000. Paul Davis, Richard W.E. Furse, and Stefan Westerfield were major contributors to the first definition of ladspa.h, and in April 2000, Richard Furse announced version 1. The version level of the SDK (software development kit) now stands at 1.09, discussion and development continue to evolve, and the library of available plug-ins has grown appreciably, along with the number of LADSPA-friendly hosts. Support for LADSPA is clearly thriving and should become a consideration in any Linux audio software design.

LADSPA's design is based upon the extensive research that has already gone into applications such as Csound and other MusicV software synthesis environments. The LADSPA architects have provided a lightweight, flexible API based upon those long-established technologies and have created a plug-in architecture as useful for software sound synthesis and mixing as it is for modular effects processing.

The LADSPA SDK currently consists of the ladspa.h header file (which defines the application program interface), ten example plug-ins, and three utility programs. We'll begin our look into LADSPA by setting up the SDK, then we'll compile and test the utilities with some of the example plug-ins.

Getting into the SDK

First, go to the LADSPA home page to pick up the latest SDK. Download the tarball (ladspa_sdk.tgz) to your $HOME directory, unpack it with tar xzvf ladspa_sdk.tgz. Next go into your new LADSPA_SDK/src directory and run make to build the sample plug-ins and utilities. Compiling is straightforward and requires no special libraries or other dependencies. When the compiler is finished, become root (su root) and run make install. Set the LADSPA_PATH environment variable with this command:

export LADSPA_PATH=/usr/local/lib/ladspa

Add that line to your shell start-up script (typically the .bash_profile or .bashrc file in your $HOME directory) for a permanent setting. You are now ready to test the sample plug-ins.

For developers, the core of the SDK is ladspa.h, a C/C++ header that defines the API following this outline:

  • Overview -- Statement of intent and functions.
  • Fundamental data type -- Defines float for data type.
  • Special plug-in properties -- Defines optional features (primarily real-time capabilities).
  • Plug-in ports -- Defines port types and restrictions.
  • Port range hints -- Type definitions for describing the typical values taken by the data (an amenity for the host).
  • Plug-in handles -- Type definition used to reference the particular instance of a plug-in.
  • Plug-in type descriptor -- Structure to describe a plug-in (name, copyright, description, etc.).
  • Accessing a plug-in -- Mechanism for basic connection between plug-in and host.

I refer the interested reader to the link above for the entire file. In keeping with LADSPA's fundamental design, the header is short, simple, and well-documented with clear relevant comments throughout. Later we'll watch the API in action when we analyze a LADSPA plug-in.

These three utilities are included with the SDK:

  • listplugins -- Lists plug-ins found in LADSPA_PATH.
  • analyseplugin -- Returns information about a plug-in.
  • applyplugin -- Tests a plug-in on a WAV file.

First, run listplugins to see what plug-ins are installed in LADSPA_PATH (by default set to /usr/local/lib/ladspa):

[dlphilp@localhost dlphilp]$ listplugins

        Mono Amplifier (1048/amp_mono)
        Stereo Amplifier (1049/amp_stereo)
        Simple Delay Line (1043/delay_5s)
        Simple Low Pass Filter (1041/lpf)
        Simple High Pass Filter (1042/hpf)
        White Noise Source (1050/noise_white)
        Sine Oscillator (Freq:audio, Amp:audio) (1044/sine_faaa)
        Sine Oscillator (Freq:audio, Amp:control) (1045/sine_faac)
        Sine Oscillator (Freq:control, Amp:audio) (1046/sine_fcaa)
        Sine Oscillator (Freq:control, Amp:control) (1047/sine_fcac)

Note that the five shared object files contain a total of 10 plug-in effects.

Now analyze one of the listed plug-ins:

[dlphilp@localhost dlphilp]$ analyseplugin

Plugin Name: "Simple Delay Line"
Plugin Label: "delay_5s"
Plugin Unique ID: 1043
Maker: "Richard Furse (LADSPA example plugins)"
Copyright: "None"
Must Run Real-Time: No
Has activate() Function: Yes
Has deactivate() Function: No
Has run_adding() Function: No
Environment: Normal or Hard Real-Time
Ports:  "Delay (Seconds)" input, control, 0 to 5
        "Dry/Wet Balance" input, control, 0 to 1
        "Input" input, audio
        "Output" output, audio

Pages: 1, 2, 3, 4

Next Pagearrow

Sponsored by: