[linux-audio-dev] exploring LADSPA

[Pete Yadlowsky]

On Wednesday 13 August 2003 06:40 pm, Brad Arant wrote:

> Would like to respond to Pete Yadlowsky...

Thanks, Brad.

> |- I've done away with the distinction between control signals and audio
> |signals.

> Early on I adopted this approach but have changed my ways as I traveled down
> the
> path for a few reasons. Actually, I have made the distinction of a control
> signal
> versus an audio path for the sake of patching. A control signal in my system
> is
> primarily a single channel signal but has all the characteristics of a
> single
> audio channel. The audio channel is actually a stereo 2x channel.

I can see that if the system has a built-in stereophonic sense that you'd want 
control and audio signals on separate "busses". However, in the system I've 
been working on (I'm calling it XAK: extensible audio kit) there's no innate 
support for any particular number of channels. I wanted the flexibility to do 
stereo, quad, septaphonic, etc, so I deliberately omitted any assumed sense 
of channel-ness. So, how to handle an arbitrary number of channels? There is 
support in place such that XAK's plugins can be written to allow for blocks 
of arbitrary numbers of input or output ports, designated during a 
post-initialization configuration phase. To configure, say, an N-output 
reverb unit:

self->outs = xak_output_bank (self, "out");

Which produces a block of output ports named out1, out2, etc. (This brings me 
to another salient feature: ports are identified by symbolic names, rather 
than numbers, granted at init/configuration time.) By this feature, one can 
patch together an N-channel audio buss of virtually any width.

> I would also like to say that I have looked at the Jack and LADSPA signal
> paths
> and I believe they are single precision floating point numbers. I personally
> have adopted the double precision format

As have I.

> and have done extensive benchmark tests and
> have found no degradation in performance

Yes. I believe double-precision is the standard data type used by most 
floating-pt processors. Single-precision floats must first be converted to 
doubles at each computation, thus actually degrading performance slightly.

> I would like to comment on this as well. The audio and signal path objects
> that
> I have described actually have the number of samples contained within a
> packet object and these are passed between the objects.

The packet idea is interesting. I'll consider it further.

> |- Every input port is a mixer/modulator.

> Internally though, I create a separate module that is
> "auto-patched"
> into the patch for two reasons; 1) I dont incur the overhead of a summation
> or modulation process if there aren't two signals to contend with

With XAK's "multi-jacked" input port, the signal sum/product is initialized 
with the value of the first feeder signal. If there are additional signals to 
deal with, only then is the necessary arithmetic performed.

> and 2) I do
> not burden the module code writer with the additional task of dealing with
> the process of summation or modulation of multiple inputs.

XAK handles this for the coder transparently by a certain function provided 
with a set of core utilities:

	sample = xak_readport (self->inport);

It seems that a LADSPA input port is basically a block of memory where 
computed samples are written. The XAK input port, in contrast, is a structure 
whose owning plugin queries it for a sample. In response, the port's feeders' 
plugins' run() methods are invoked, who in turn query their input ports, and 
so on up the chain. One complete chain reaction, driven by xak_readport() 
above, constitutes a single sample run.

I have written Python bindings for XAK to facilitate test and experimentation, 
and to simplify the construction of complex networks of plugins and lists of 
events to drive them.

I get a sense from postings to this list that this group is primarily 
interested in real-time synthesis. RT doesn't interest me so much at this 
time, partly because I'm running on a clunky old 400MHz machine, and partly 
because I'm more interested in the purity of the idea than I am in wringing 
every last drop out of each machine cycle. The hardware will inevitably get 
faster, but at least for now I'll be content to churn out gigabytes of sound 
files.

	- Pete