This is the DLADSPA README file for version 0.1.
Copyright (C) 2003 - Nelson Posse Lago
This file is part of DLADSPA, a system for distributed processing of LADSPA plugins.
DLADSPA is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
DLADSPA is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA or just check their website at http://www.fsf.org
- What?
This is a basic implementation of a mechanism for the distributed processing of LADSPA plugins. Given a machine with a soundcard and a buch of other machines connected to it, you may have the "auxiliary" machines execute LADSPA plugins on the audio data that is captured/played by the machine with the soundcard in realtime and with very low latency. This means that you are not limited to the processing power of a single CPU to process the audio anymore. Sure, a bunch of machines interconnected and synced with "word clock" would give you the same, but that would be more expensive and more difficult to work with (because you would have a buch of unrelated programs running simultaneously on different machines).
The price you pay for this system to work is that the latency of the system is usually increased by one period. That is, if you are using JACK with nframes=64 @44.1KHz and nperiods=2, your total latency will be increased from 2.9ms to 4.35ms. If nframes=128 @96KHz and nperiods=2, your total latency will be increased from 2.67ms to 4ms.
The current status of the system is "it seems to work for me". See the TODO for the not-so-exciting list of future improvements.
2. Compiling
You will need gcc 2.95, MICO or OmniORB and libxml2. I used MICO 2.3.5, OmniORB 3.0.4.1 and libxml2 2.5.4. Please note that apparently there are bugs when using MICO.
Just type make and hopefully everything will compile ok. Now copy the generated pluin_factory executable to all the "auxiliary" machines (don't forget to also install your ordinary LADSPA plugins on these machines), put the manager executable on a reasonable place, like /usr/local/bin, and put the library remote_plugins.so somewhere on your LADSPA_PATH. Finally, create the directory /usr/local/lib/dladspa.
3. Using
Normally, you will want to perform all the processing for a single audio channel on a single (remote) machine. Therefore, it must be possible to define a sequence of plugins to be applied to the audio data on the remote machine (in the future, we may also make it possible to define plugin graphs). To do this, we will create a "meta ladspa-plugin" that is to be run remotely. This "meta-plugin" is, in fact, a sequence of ordinary plugins accessible as any other ladspa plugin.
To create this meta plugin, first you need to download jack-rack (http://pkl.net/~node/jack-rack.html). I used version 1.4.2. With it, create a sequence of plugins that you want to run remotely (say, a gain plugin followed by a compressor followed by an EQ). Save the rack (note that the "enabled" and "lock all" buttons affect how the system will deal with the plugins later; in the future, the wetness control will also work). The saved file is compressed; you need to decompress it with gunzip (zcat file.rack > uncompressed.rack). Now rename it to NUMBER.rack, where NUMBER is between 1 and 999. This number will be the UniqueID of the meta-plugin. Put this file in /usr/local/lib/dladspa.
Now start the CORBA name service on some machine on the network; the MICO
nameserver should be called like this:
nsd -ORBNoResolve -ORBIIOPAddr inet:MACHINE_IP:PORTNUM
Start the servers on the "auxiliary" machines; for OmniORB, this is the syntax: plugin_factory -ORBInitRef NameService=corbaname::NAMESERVER_MACHINE_IP:PORTNUM
And start the manager on the "main" machine: manager -ORBInitRef NameService=corbaname::NAMESERVER_MACHINE_IP:PORTNUM
If you are using MICO, these should be: plugin_factory -ORBNoResolve -ORBNamingAddr inet:NAMESERVER_MACHINE_IP:PORTNUM manager -ORBNoResolve -ORBNamingAddr inet:NAMESERVER_MACHINE_IP:PORTNUM
PORTNUM may be any port number higher than 1024. While you might want to use hostnames instead of addresses, things may get a little complicated due to the interaction between the CORBA nameserver and DNS.
Finally, put the compiled "remote_plugins.so" somewhere on your LADSPA_PATH and start the application you want to use. The meta-plugin will appear in the list of available LADSPA plugins. When you ask to instantiate it, the application will block and the manager will ask you on which machine you want to create the plugin. Choose one from the list of available machines and voila'!
Please note that the plugin_factory application must have the LADSPA_PATH environment variable defined and pointing to your collection of LADSPA plugins. Also note that the remote_plugins.so library should not be in this LADSPA_PATH.
To achieve low latencies, the plugin_factory program must be able to run with realtime priority, which means it must be able to run as root. It is also important that you have a kernel with some kind of low-latency patch applied.
The plugin instantiated by the application communicates with the manager via TCP; by default, the manager listens on localhost, port 3000. If you want to change that, set the environment variable DLADSPA_MANAGER to the address:port you want and use the command-line parameters of the manager to make it listen to this address.