Development

A survey of Linux audio plugins

Whether for a word processor, an image editor, or a Web browser, plugins have become a common characteristic of modern application software design. An audio plugin functions generally in the same manner as any other kind of plugin: it extends the capabilities of the host application in some way. For example, a DAW (digital audio workstation) may have its own reverberation effect, but if the workstation supports plugins I can substitute a 3rd-party reverb plugin with preferable features and sound quality.

Plugins for audio purposes face performance constraints not commonly encountered by plugins for non-audio applications. An audio plugin is typically expected to perform some process on an incoming data stream, possibly in realtime, and the processing should take place with minimal disruption to the timing and audio quality of the affected stream. Latency becomes a critical issue if the process takes more time than the data stream permits, at which point mechanisms for latency compensation may be invoked. Many control processes can take place in realtime with no undesired effects while others require considerable care in their deployment. Some parameters of a plugin may be adjusted in realtime without concern, while others may involve considerably larger data and/or longer processing, thus raising the likelihood of dropouts and other forms of audio corruption. Programmers must resolve these and other problems if they expect their plugins to be acceptable in performance-critical cases.

Linux audio enthusiasts can choose native plugins from a variety of acronyms, of which DSSI, LADSPA, LV2, and VST are the best known and developed formats. In addition to these Linux formats, limited support is available for non-native VST plugins. In this article I'll present some of the technical details of these formats along with some of their outstanding examples, beginning with LADSPA.

LADSPA - Keeping It Simple

LADSPA is an acronym for the Linux Audio Developers Simple Plugin API. As its name implies, the format was designed with simplicity as a first consideration. The LADSPA API is easy to understand and implement (see ladspa.h for the details), and its practical design led to rapid adoption throughout the Linux audio development community. The plugin format is best employed for adding special effects such as distortion, echo, or reverb; for dynamics processing (compression, limiting, normalization); and for spectral processing with filters or equalizers. Thanks to its uncomplicated API more than two hundred LADSPA plugins are currently available, and compatible host applications now include DAWs, soundfile editors, dedicated processor racks, and video editing suites.

The format's self-imposed austerity does have its drawbacks. Instrument plugins (those which, like ordinary instruments, create sounds rather than modifying them) are not well-supported, though some plugins provide "building-blocks" for audio synthesis. The API's most conspicuous limitation is its non-support for any GUI toolkit. The host application provides the GUI, so if your DAW is built with Qt your LADSPA plugins will appear in a Qt-based GUI. Depending on your point of view, this particular limitation is a blessing or a curse, but it is difficult to argue against the logical decision of the original developers. By keeping the GUI out of the framework, the developer's focus remains on the plugin's processing capabilities. Users may not get pretty pictures with LADSPA but they do get some pretty good plugins.

I use only a few plugins with my own recordings, and I tend to use plugins I know well enough to predict their response to the material, most of which is either straightforward song composition or not-so-straightforward electroacoustic experimentation. The songs get the plugins, while experimental music typically includes its own processing. For the sound quality of my voice and guitar I like the Versatile Plate Reverb from Tim Goetze's C* Audio Processing Suite. I keep a basic setting for it, but since the effect has only a few parameters I tune it a little differently every time I use it. My guitar typically gets treated further by Steve Harris's DJ EQ, a 3-band equalizer I find handy for quick fixes to my cheap guitar's less than lovely tone. Last but far from least, Steve's SC compressor/limiter plugins are also commonly employed as final dynamics processors in my master track.

The rest of this article deals with plugin formats that have evolved since LADSPA, but I assure readers that LADSPA itself is alive and well. The Guitarix project has formatted some of its processors as LADSPA plugins, and the developers at Harrison Consoles thought that the format's capabilities were sufficient for some of the internals of Mixbus, their enhanced version of Ardour2. Harrison programmers have also developed excellent GUIs for some LADSPA plugins (as seen on the right), prompting me to hope that Harrison might consider developing more such plugins for general distribution.

LV2 - The Heir Apparent

After LADSPA's initial success developers started to consider the next stage in the evolution of high-performance audio plugins for Linux. LADSPA's limitations were too severe to allow the required expansion of capabilities, so work began on new formats that would permit such amenities as embedded graphic envelope editors and synchronized clock control for delay effects. The LV2 format has been designed to supersede LADSPA, to address the earlier format's limitations and to provide new capabilities to plugin developers. The full specification can be read at the LV2 Trac page.

LV2's chief developer Dave Robillard recently announced that the format has attained 1.0.0 release status. Along with this news comes Dave's LV2 ports of the MDA plugins by Paul Keller, a set of thirty-six plugins that includes a variety of instruments and audio signal processors. Developer Nick Bailey has released test versions of his Minaton and Triceratops synthesizers, and developer falkTX recently announced the availability of his DISTRHO project, a collection of LV2 versions of instruments and processors from other projects, most of which were originally developed for Windows audio plugin hosts. These additions expand a collection that already includes fine work from Steve Harris, Tom Szilagyi, the CALF developers, and the Invada group. It's worth noting that many of these programmers are also known for their involvement with LADSPA-based projects.

Tom Szilagyi's IR is a fine example of an advanced LV2 plugin with outstanding audio capability and rich display features. IR processes an input signal with data from an impulse response file, i.e. a kind of soundfile snapshot of the reverberant characteristics of an acoustically interesting environment. This processing method is called convolution, and it is an effective way to achieve high-quality reverb effects without purchasing expensive hardware and airline tickets to the great cathedrals of Europe. Many free and non-free collections of response files are available on-line, or you can create your own with only an interesting acoustic space and some software from Fons Andriaensen, a true DSP wizard of the Linux audio community.

Special mention must be made of the plugins from linuxDSP. These plugins are among the best available for Linux - they aren't free, and they're not open-source, but they are reasonably priced, multiformat, professional-grade audio plugins. At this time all linuxDSP plugins are signal processors - EQ, compressor, reverb, etc. - but the developer has hinted at the production of a linuxDSP synthesizer plugin. Given the quality of his DSP work I'm eager to hear what he can do with an LV2 synth plugin.

As I put the final touches to this article I learned of new sets of LV2 plugins from developers Joe Button and Rui Capela. Interest in the format is clearly growing since the announcement of its milestone release, and I look forward to seeing more work from more Linux plugin developers. Indeed, LV2 appears to be on track to become the standard for Linux audio plugins.

DSSI - A LADSPA For Instruments

DSSI - the Disposable SoftSynth Interface - is a project originally headed by developers Chris Cannam (one of the original and current developers of the Rosegarden DAW), Sean Bolton, and Steve Harris. Like LV2, DSSI addresses a number of shortfalls in the LADSPA format, particularly regarding instrument plugins. In fact, DSSI is essentially a wrapper for a LADSPA plugin with the addition of an OSC (Open Sound Control) interface for toolkit-agnostic GUI and MIDI control, features notably missing in LADSPA. This approach reflects the author's desire to create a "LADSPA for instruments" that retains the simplicity of the earlier format while providing new mechanisms for features not included in the LADSPA API. The OSC protocol is also an easily implemented method of establishing communications between programs or parts of programs (as it's used in DSSI). Interested developers can peruse the complete DSSI specification for more information and full details on implementing the format in their own applications.

Notable DSSI plugins include Sean Bolton's Hexter and xsynth synthesizers for FM and analog sounds, the Fluidsynth-DSSI soundfont synthesizer, and Nick Dowell's amSynth. The neko* synths, WhySynth, and the HOLAP suite are also worthy entries to the list.

Jeff Hubbard's LibModSynth project demonstrates that DSSI lives and continues to evolve. The project has already given us a development library (libmodsynth), a synthesizer (Ray-V, seen to the right), a variety of effects processors, and a sampler under construction. Jeff is dedicating his efforts to expand awareness of DSSI's potential, and his contributions are eloquent proofs. I hope he continues to expand the LibModSynth suite and that other Linux plugin developers will consider adding their efforts to the cause.

VST/VSTi - The Steinberg Standard

In 1996 the programmers at Steinberg GmbH developed the VST plugin format for use with the Cubase DAW for Windows. The company released a development kit with agreeable licensing conditions that fostered the rapid growth of an industry of 3rd-party VST plugin designers. Other host manufacturers quickly supported the format - the host/plugin architecture was a win for everyone - and a wave of VST plugins hit the market. The VSTi specification extended the format's capabilities to include virtual instruments, another win for everyone. VST/VSTi plugins now number in the thousands, ranging in cost from free to expensive, and varying likewise in quality and utility.

Musicians who want to migrate from Windows often inquire about the feasibility of running their VST plugins under Linux. Limited support does exist for native Windows plugins, but the extent of that support varies dramatically. At least three methods currently exist for running Windows VST/VSTi plugins under Linux - the fst software, the dssi-vst-wrapper bridge utility, and the use of a Windows DAW such as Reaper running under Wine. However, in my opinion support for native Windows VST plugins should be considered experimental. Some plugins will work with any of these methods, others with only one, some will run very well, others not at all. The version of Wine can have significant impact on performance, and all Linux VST support mechanisms depend on Wine.

Steinberg's terms are non-problematic for Windows programmers, but they are not amenable to FLOSS developers. The license forbids the free redistribution of the API, and there is no indication from Steinberg that they will ever alter their policies. Despite the format's problematic legal aspects the demand remains and designers must respond. Fortunately, thanks to some clever reverse-engineering from Javier Serrano Polo's VeSTige project, Ardour3 and QTractor can be compiled with support for native Windows VSTs, and LMMS includes a module that provides a VeSTige-based VST-to-Linux bridge. FeSTige is a convenient VST/VSTi plugin launcher that will eventually be replaced by its evolving offspring Carla, a multiformat launcher from developer falkTX. Clearly, users want to be able to deploy their VST plugins under Linux. Some developers will avoid the issue by refusing to support a non-native format, while others see and pursue a unique opportunity.

Some VST/VSTi plugins can be compiled as native Linux shared object files (e.g. fooplug.so) that require no dependency on Wine. Commercial plugin developers have been quick to adopt the format - the current catalog of Linux VST plugins includes excellent instruments and processors from Loomer Software (pictured, right), discoDSP, and linuxDSP. Some excellent MIDI plugins can be found in the pizmidi and Mucoder collections, both of which are freeware, not open-source free software. The FLOSS audio development community has been less productive with the format, though notable work has been done by the ccern and the Jucetice projects. It remains to be seen whether the catalog continues to expand, and that depends most of all upon the quality of the processors and instruments created for it.

Plug In The Future

The stabilization of LV2, the renewed interest in DSSI, and the continuing utility of LADSPA point to a positive outlook for audio plugins for Linux. Commercial interest is likely to maintain a focus on the VST format - it does own the largest market share, and native Linux support might open a door for enterprising Windows VST developers. New cross-platform development tools promise easy output to multiple targets and new hosts are appearing on the Linux applications stack. From where I stand the future of Linux audio is sounding better all the time.

Comments (16 posted)

Quotes of the week

— Avery Pennarun

— Joey Hess

Comments (12 posted)

DigiKam 2.6.0 released

Version 2.6.0 of the photo editing and organizing suite digiKam has been released. The release includes a new maintenance tool for automating tasks, and support for new Kipi plugins.

Comments (none posted)

PacketFence 3.4.0 released

The PacketFence team has released version 3.4.0. "This is a major release with new features and important bug fixes. This release is considered ready for production use and contains a security fix so upgrading to 3.4.0 is advised."

Full Story (comments: none)

SystemTap 1.8 released

The SystemTap project has announced the release of version 1.8. "There is updated support for user-space probing against kernels >= 3.5, which have no utrace but do have the newer inode-uprobes work by Srikar Dronamraju and colleagues." The release also includes improved IPv6 support and multiple concurrent connections.

Full Story (comments: none)

Ulogd 2.0.0 released

Version 2.0.0 of the ulogd userspace logging daemon for netfilter has been released. This release "requires a Linux kernel >= 2.6.14, but Linux kernel >= 2.6.18 is strongly recommended. Note that if you need SQL database output [support], you will need the header files of the respective libraries."

Full Story (comments: none)

Development newsletters from the last week

• Caml Weekly News (June 19)
• What's cooking in git.git (June 15)
• GCC 4.5.4 Status Report (June 20)
• The Haskell Weekly News (June 13)
• Perl Weekly (June 18)
• PostgreSQL Weekly news (June 17)
• Ruby Weekly (June 18)

Comments (none posted)

The state of FireWire audio interfaces support on Linux (Libre Graphics World)

Libre Graphics World has an extensive examination of Linux support for Firewire audio interfaces often used in professional sound work. The story includes interviews with developers from the Free FireWire Audio Drivers (FFADO) and ALSA projects. "The ease at which FFADO can shift its streaming subsystem into the kernel comes about because of the way that device streaming and control has been carefully separated from the very beginning. This means that we can remove the streaming parts without affecting device control in any way. In fact, even now the device control part of FFADO would happily run on a system with a hypothetical kernel streaming driver."

Comments (none posted)

Health care privacy discussed as an aspect of patient control (O'Reilly Radar)

Andy Oram has written a thorough write-up of the 2012 Health Privacy Summit at O'Reilly Radar. "We can fix our health care systems if we educate doctors and patients to work together; create teams that have incentives to deliver the best care; open up data about the health care industry; incorporate low-cost devices into patient-centered medical homes, and incorporate the best research into clinical decision support. I'm sure readers could suggest other related elements of a solution. A crucial background role will be played by technological improvements and standards." Readers interested in healthcare IT will also want to follow the links to Oram's recaps of the co-located Patient Access Summit and Health Data Initiative forum.

Comments (none posted)