[LAD] ladspa scheduling questions

Fons Adriaensen fons at kokkinizita.net
Sat Oct 3 22:38:34 UTC 2009


On Sat, Oct 03, 2009 at 05:15:59PM -0400, Simon Burton wrote:

> I am writing a ladspa host, some kind of modular synth with a python front-end.
> 
> In terms of the scheduling algorithm, I was just going to do a topological sort
> and then run each plugin from the sources to the sinks. If there is a loop (does
> this even make sense?), well i'm not sure what to do there, perhaps it is up to
> the script to specify the order.

The normal way to evaluate a signal flow graph is a depth-first
order traversal of the connection graph, starting at the outputs.
If there is more than one output this requires some extra logic
to avoid running a module twice or more if more than one output
depends on it. 

The DF search can be done once and the result stored each time
the connections change (as jackd does), or implicity run on each
cycle (as AMS does).

> The other thing I noticed is that plugins are expected to completely fill and/or
> drain their buffers (ports). Doesn't this mean it's impossible to make a resampling 
> plugin with LADSPA ?

Correct. The run() method of a LADSPA plugin gets a single
parameter giving the number of samples to process, this is
the same for all ports. AFAIK there is no Linux plugin
standard that supports resampling.

Note that in the general case this takes more than just
specifying a sample rate or number of samples per port.

Assume you are resampling from 48k to 44k1, and your app
is a jack client supposed to process jack_period_size
samples at 48k in each cycle. Assume this period is 256.
Then the resampled signal will contain either 235 or 236
samples. In fact it will be a sequence of length 5:
[ 235, 235, 235, 235, 236 ]. The sum of this is 1176,
corresponding to 1280 input samples, and 1280/1176 =
48000/44100. 

Now if these output samples are e.g. written to a file
there is no problem. But if there is, further down the
processing stream, a plugin that converts back to 48k
then this plugin needs to know to the current index into
the repeating sequence in order to be able to produce
256 output samples in each cycle. That means that the
index into this sequence has to be a property of the
44k1 port type, shared by all plugins that use this
rate. 

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.




More information about the Linux-audio-dev mailing list