Ecasound LADSPA Plugin Naming Conflict Resolution

This article explains how the Ecasound digital audio processing tool resolves plugin naming conflicts when multiple LADSPA libraries share the same textual labels or identifiers. It covers the hierarchy of plugin resolution, the priority defined by directory search paths, and how relying on unique numerical identifiers allows users to bypass label collisions entirely.

Textual Labels vs. Numerical Identifiers

The Linux Audio Developer's Simple Plugin API (LADSPA) defines plugins using both a textual label (a short, machine-readable string like amp or delay) and a unique 32-bit integer identifier (UniqueID). While the LADSPA standard intended for textual labels to be unique, collisions frequently occur when developers fork plugins, distribute different versions of the same library, or use generic naming conventions across different .so files.

Ecasound supports two primary operators for invoking LADSPA plugins:

• -el:plugin_label,param1,param2,... references a plugin by its textual label.
• -eli:plugin_unique_id,param1,param2,... references a plugin strictly by its unique integer identifier.

Resolution via LADSPA_PATH Hierarchy

When a plugin is invoked by its textual label using the -el option, Ecasound searches for the plugin binary across directories defined in the environment variable LADSPA_PATH (or its default system fallback directories, typically /usr/lib/ladspa and /usr/local/lib/ladspa).

If two distinct shared object files in different directories contain a plugin with identical labels:

1. Ecasound parses the colon-separated directories in LADSPA_PATH sequentially from left to right.
2. The first shared object file encountered containing the requested label is used to instantiate the plugin.
3. Subsequent libraries containing matching labels found later in the search path are ignored for that label lookup.

Same-Directory and Internal Collisions

If multiple .so files in the exact same directory contain duplicate plugin labels, resolution depends on the order in which the underlying operating system's dynamic linker loads the directory's directory entries. Because this order is non-deterministic and can vary across filesystems or system reboots, relying on textual labels in conflicting environments can cause unstable routing behavior.

Avoiding Conflicts with Unique IDs

To definitively prevent ambiguous behavior, Ecasound's design offloads conflict resolution to the -eli parameter. The LADSPA specification maintains a centralized registry of integer IDs, making the UniqueID mathematically deterministic and unique across all valid LADSPA plugins.

By replacing -el:label with -eli:id inside Ecasound chains, scripts, or interactive commands, Ecasound ignores textual labels entirely. It scans all shared objects until it matches the specific, registered integer ID, ensuring that the intended plugin is initialized regardless of identical names or directory placement.