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, > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
