LADSPA Host now working. Please try it!
After some more work, I have now the LADSPA host in a nice working state. One of the harder things was allowing hot swapping of the LADSPA plugin while xmms2 was playing. And after a talk with oneman, I decided to do it the *perfect* way by allocating the new plugin and structures separately and then locking the structure only to swap the pointers, after which the old plugin, buffers and structures are freed.
The LADSPA host currently supports both S16 and float samples so it should be compatible with most (if not all) of your music. Please give it a go and report any bugs! Also any ideas or suggestions are very welcome. My git repo is here:
So how is it used?
After building and installing the ladspahost xform plugin, you have to add the LADSPA host to the effects chain:
nyxmms2 server config effects.order.0 ladspa
Then you need to choose the plugin you want to use from your LADSPA plugins. They are usually found on /usr/lib/ladspa. The xmms2 LADSPA host will look for plugins which don’t have an absolute path in the LADSPA_PATH environment variable, and if it’s not available in /usr/lib/ladspa, so you only need to do:
nyxmms2 server config ladspa.plugin amp.so
to load the /usr/lib/ladspa/amp.so plugin.
LADSPA plugin libraries can actually contain more than one plugin. If you don’t specify which one you want, the first plugin in the library is loaded. You can find out about the contents of particular plugins by using the LADSPA analyseplugin tool, like this:
which will produce:
Plugin Name: "Mono Amplifier" Plugin Label: "amp_mono" Plugin Unique ID: 1048 Maker: "Richard Furse (LADSPA example plugins)" Copyright: "None" Must Run Real-Time: No Has activate() Function: No Has deativate() Function: No Has run_adding() Function: No Environment: Normal or Hard Real-Time Ports: "Gain" input, control, 0 to ..., default 1, logarithmic "Input" input, audio "Output" output, audio Plugin Name: "Stereo Amplifier" Plugin Label: "amp_stereo" Plugin Unique ID: 1049 Maker: "Richard Furse (LADSPA example plugins)" Copyright: "None" Must Run Real-Time: No Has activate() Function: No Has deativate() Function: No Has run_adding() Function: No Environment: Normal or Hard Real-Time Ports: "Gain" input, control, 0 to ..., default 1, logarithmic "Input (Left)" input, audio "Output (Left)" output, audio "Input (Right)" input, audio "Output (Right)" output, audio
As you can see, this plugin library has two plugins inside. To specify which plugin you want to use, you need to add the plugin name, plugin label or unique ID (any one of these will work) after the library name with a colon, like this:
nyxmms2 server config ladspa.plugin amp.so:1049
Once you have loaded a plugin, you can see the available controls by checking the ladspa properties, which will have adjusted to the plugin, an easy way is:
nyxmms2 server config | grep ladspa
which can show something like:
effect.order.0 = ladspa ladspa.control.0 = 7000 ladspa.control.1 = -90 ladspa.control.2 = 30 ladspa.control.3 = 1 ladspa.control.4 = 1.000000 ladspa.control.5 = 1.000000 ladspa.control.6 = 1.000000 ladspa.control.7 = 0.000000 ladspa.controlname.0 = Decay [ms] ladspa.controlname.1 = Dry Level [dB] ladspa.controlname.2 = Wet Level [dB] ladspa.controlname.3 = Comb Filters ladspa.controlname.4 = Allpass Filters ladspa.controlname.5 = Bandpass Filter ladspa.controlname.6 = Enhanced Stereo ladspa.controlname.7 = Reverb Type ladspa.enabled = 1 ladspa.plugin = tap_reverb.so ladspa.priority.audio/pcm = 50
You can change the control values for a plugin like you would any other xmms2 property:
nyxmms2 server config ladspa.control.3 0
Properties will be retained and used across songs and across server reboots, but will be lost if you change the plugin.
Current limitations and future work
- Since configuration parameters can’t be removed, if the previous plugin you loaded had more controls, there will be some useless controls (which you can identify because they will have no name). Additionally since config parameters live on, you will always tend to have more controls than the plugin actually supports. When arrays are implemented, it is likely that this problem will be resolved as configuration keys that are arrays should resize automatically to the number of elements in the array.
- Although the internal data structures are designed to support plugin chains, this is not yet exposed to the user, as I’m waiting to implement the schema system for properties, which will allow doing this simply (See my previous posts).