|Developer(s)||Steve Harris, David Robillard, other members of linux-audio-dev|
|Written in||C and Turtle|
LV2, an acronym for LADSPA Version 2, is a set of royalty-free open standards for plug-ins and matching host applications. It includes support for the synthesis and processing of digital audio and CV,  events such as MIDI and OSC, and provides a free alternative to audio plug-in standards such as Virtual Studio Technology (VST) and Audio Units (AU).
LV2 succeeds the more limited Linux Audio Developer's Simple Plugin API (LADSPA) standard and replaces the Disposable Soft Synth Interface (DSSI) plugin infrastructure ("LADSPA for instruments"), adding abilities such as MIDI capability, custom UIs, and a system allowing extensibility of the initial standard.
Over a thousand plugins are now available in LV2 format. Notable plugins include Calf Studio Gear and Surge. Software that can host LV2 plugin "bundles" includes Ardour, Ingen, Carla from KXStudio, Qtractor, Traverso DAW, Harrison Mixbus, MusE, Audacity, Ecasound, FFmpeg, the GStreamer framework and DJing software Mixxx. It is also the plugin format used by the MOD Duo and MOD Duo X  and Zynthian hardware units.
LV2 is an extensible framework, allowing a program to load a plugin to do some processing. Note that the terms used here are generic on purpose because LV2 allows any type of data to be exchanged between the host and the plugin.
The LV2 specifications are defined by and make use of RDF metadata in Turtle format. Technologies involved include Dublin Core, FOAF, DOAP, XSD, RDFS and OWL. The relational capabilities and properties this syntax supports are powerful but can be hard to understand at first.
Beyond the core specification there are 21 official extensions providing support for host options, plugin presets, time and units, port buffers, properties, groups and parameter labels, for sending MIDI, patches, UI events and more. There are various non-core extensions for supporting expressive events, OSC, and MOD Devices specific hardware and software, with three in the KXStudio LV2 Namespace.
The plugin uses this information to provide a list of capabilities to the host, so the host can accommodate those. Similarly, the host can provide a list of LV2 extension capabilities that it supports on initialization of the plugin.
In the example below, first the lv2 and doap ontology shortcut prefixes are declared. Next, every plugin must have its own URI. Then the 4 following lines declare that this resource is an lv2:Plugin, a binary object file library with the filename silence.so should be present, that the plugin is known under the name Silence, and is licensed under the GNU GPL. These 4 properties are mandatory for an LV2 plugin; if a plugin does not have all of them a host might not load it.
@prefix lv2: <http://lv2plug.in/ns/lv2core#>. @prefix doap: <http://usefulinc.com/ns/doap#>. <http://ll-plugins.nongnu.org/lv2/lv2pftci/silence> a lv2:Plugin; lv2:binary <silence.so>; doap:name "Silence"; doap:license <http://usefulinc.com/doap/licenses/gpl>; lv2:port [ a lv2:AudioPort, lv2:OutputPort; lv2:index 0; lv2:symbol "output"; lv2:name "Output"; ].
"Atom" data structures are used for messaging between plugin ports for the transfer of MIDI, OSC, Patch, UI and other events between plugin instances. These can also be serialised to Turtle. 
Aside from separating metadata from binaries, LV2 mandates a general separation between DSP and user interface processing. Benefits include that UI processing cannot hold back DSP processing, and UI and DSP can be separated across a network. Messaging using Atoms is the preferred method for passing updates between the running DSP and UI binaries.
Hosts can also provide an interface for displaying and configuring the properties of plugin instances. There are extensions and properties to help display the correct control types.
One capability that a host can provide to a plugin is a "worker thread". In programming terms, this means that the plugin can offload some work to be done in another thread that the host provides. This is generally useful because a plugin is usually run in the real-time audio thread of an application, and hence cannot do any non-real-time safe operations (disk-accesses, system calls, etc.). To make it easy for the plugin to achieve its goals (e.g.: load a file from disk), the host can provide a worker thread. The host provides the LV2_Extension for the worker thread and the plugin is then able to use it.
There are tools and frameworks available to assist with in creating LV2 plugins. These include DPF (DISTRHO Plugin Framework), two forks of JUCE, Faust, Dplug, iPlug 2 (alpha), and Cabbage (alpha). There is also the ability to load Pure Data patches as well as JIT-run Faust, Rust, Lua or C code in certain LV2 plugins. For information exchange and discussions about LV2 there are user and developer mailing lists, along with the #lv2 and #lad channels on freenode IRC, and forums such as LinuxMusicians.
- JACK/LV2 CV - LinuxMusicians
- List of LV2 features
- drobilla.net : LV2: The good, bad, and ugly
- List of 1000+ plugin uris  site.
- "Calf Studio Gear supports LV2".
- "Traverso User Manual, p. 26" (PDF). Archived from the original (PDF) on 2016-04-23. Retrieved 2020-02-21.
- Harrison Website
- Audacity Archived 2008-09-29 at the Wayback Machine
- "MOD Devices". moddevices.com. Retrieved 2016-04-16.
- drobilla.net : Writing an LV2 Book
- Programming LV2 Plugins book with example plugins.
- LV2 Atoms: A Data Model for Real-Time Audio Plugins (PDF)
- drobilla.net : LV2 atom and state serialisation -
- https://github.com/lv2/sratom - a small C library for serialising LV2 atoms to and from RDF, for converting between binary and text or storing in a model.