[LAD] ladspa scheduling questions

Stefan Kost ensonic at hora-obscura.de
Wed Oct 7 13:04:44 UTC 2009


Fons Adriaensen schrieb:
> 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.
>   
except gstreamer (although such features don't come for free and impose
other restrictions).

Stefan
> 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,
>
>   




More information about the Linux-audio-dev mailing list