Subject: Re: [linux-audio-dev] extending LADSPA, it's not that easy ......
From: David Olofson (david_AT_gardena.net)
Date: Tue Nov 07 2000 - 03:30:56 EET
On Mon, 06 Nov 2000, Paul Barton-Davis wrote:
> >Well, I have "simple" answers for all of those questions, and it's no
> >big deal to implement it. However, if it's a part of the API all
> >hosts and/or plugins *have* to deal with it one way or another, or
> >we'll soon end up with lots of "classes" of LADSPA plugins, which
> >won't run on host of all other classes, and/or won't work together
> >with plugins of certain classes. Not very nice, especially not for
> >the end-user.
>
> we already have this. LADSPA allows a plugin to not implement
> run_adding(). some hosts may have good reasons to not run such
> plugins. as far as i could tell, most plugins in the CMT set (thanks,
> richard!) don't implement run_adding(). not nice.
One starts to wonder which is most evil; forcing developers to
implement run_adding(), or forcing hosts to cope without it... (And
that's basically the issue with all features of this kind.)
> >Now, if we *really* want to implement this (rather than just hinting
> >some audio ports as actually being audio rate control ports), the
> >simplest way would be to decide on a single control sample rate,
> >based on a fixed relation to the audio sample rate. This fixed rate
> >should be somewhere between the two existing rates; the audio sample
> >rate (about 32..96 kHz) and the control rate (300-3000 Hz, depending
> >on how much overhead you can tolerate.)
>
> bzzzt! csound experience alert! there is *no* single control rate that
> works. thats why its configurable at run time, and thats why some
> settings will totally break certain csound instruments and/or crucify
> the performance of others.
Yeah; why do you think I'm still messing with events? ;-)
The problem is that it always comes to a balance between
* Plugin complexity
* Host complexity
* Overhead
* Quality
All of these are basically exclusive according to some some weird
scheme, with plugin and host complexity sticking together in some
cases, usually balancing against the other two. (Well, there are
more than two, but this is messy enough, doesn't it? :-)
One advantage with audio style control signals is that they're
possible to deal with efficiently. OTOH, if they're not fixed to a
rate that is hardcoded into plugins, they start to generate either
lots of overhead, lots of different versions of the run()
implementations, or code complexity + some overhead.
Events cost nothing when they're not used (well, there will be *one*
pass through the outer event loop per plugin call when there are no
events), and there can be any number of possible destinations.
Control rates are fully dynamic, and plugins don't have to worry
about frequency conversions or different rates on different ports, as
event timestamps rule all timing.
However, when a control destination is given a "stream" of events in
order to operate as a control port, there is significantly more
overhead. Maybe this should be considered abuse of such an API, it's
still a kind of functionality that will have to be supported somehow.
Ok, it's faster than running LADSPA plugins one sample at a time, but
it's still painfully inefficient compared to real streams.
So, how about Control Destination (C. Target, Parameter, whatever)
being defined this way:
A Control Destination must always be writabe using events.
(These events correspond to MIDI CC.) The plugin should, if
applicable, respond to events at any frequency up to, and
including the main audio sample rate.
A Control Destination *may* support reading streams as an
alternative interface. These streams should use the main audio
sample rate, and should expect to deal with signals in the
audio frequency range. (That is, it doesn't make much sense
to provide streaming support for Control Destinations that
won't react to audio frequencies.)
Streaming, when enabled, *overrides* event control. Sending
events to a Control Destination that is receiving stream data
is not allowed, and plugins do not have to handle it.
(Output data is left out here - should work about the same way.)
This could be applied to LADSPA as well, as a way of saying that the
plugin has a mode that treats control ports the same way as audio
ports. (In other words, events basically correspond to splitting
buffers with LADSPA.)
But obviously, even this very simplified black/white (massive
overhead/audio signals for everything) solution means that we're back
to the usual implementation problem: To do this efficiently, you need
to make it global for the plugin (ie not per port), and implement it
in different run() functions. That's four versions with _adding()...
Yep, this is already "implemented" in LADSPA (see CMT), but on a
higher level; some plugins come in versions where the control ports
have been replaced with audio ports. That's probably the way to do it
for extreme control rates. The remaining question (for a new API at
least) is what interface to use for low and medium control rates.
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Nov 09 2000 - 05:12:10 EET