Subject: Re: [linux-audio-dev] API design again
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: ke loka 06 1999 - 14:05:53 EDT
Paul Barton-Davis wrote:
>
> >The big advantage:
> >==================
> >
> >Plugins can be written as ever without taking care of the applications
> >implementation, be that fixed buffers, the events system,
> >single sample (only for networks with recursions).
> >
> >The plugin programmer only has to take care that the plugin works
> >with different block sizes down to 1.
>
> Thanks.
>
> David has raised concerns about efficiency, which I think probably
> refers to the function call overhead associated with this
> situation. Notice that:
>
> process the event
>
> probably involves something like:
>
> pluginobj->notify (event)
>
> for each (active?) plugin.
Yes but the event is supposed to affect the current executing plugin
only (my interpretation) and can then be coded as:
selfHandleEvent(event); // could be inlined by the compiler,
// or at least it is a static call, no miss in jump prediction.
engineGetNextEvent(this, event); // Have not seen this
shouldn't we be able to process more than one event during one
buffer....
(or was the event a linked list)
[Side note: misses in jump prediction are costly. You have to restart
the
processors pipeline. You can avoid misses in selfHandleEvent by
treating
the event as an (index,value) pair and only doing:
static inline selfHandleEvent(event) {
int index = event.index;
float value = event.data;
if (index >= 0 && index < maxParameter) ... // predicated correctly
parameter[index] = value; // instead of switch(index)]
}
]
It also does simplify coding for FFT since you get the same size all the
time,
you would probably need less memory to keep state from previous.
(Especially
if the plugin can specify buffer size)
>
> So you could end up calling 3N where N is the number of active plugins
> instead of just N. Given that in some cases, the samples_to_process
> might be very small, the function call overhead of this scheme is not
> necessarily small, although most of the time, it probably will be
> because the event density is so low.
>
> However, the benefit of the plugin's own code being *independent* of
> the API framework seems enormous. One of my concerns about David's
> proposed event system is the amount of work it would take to port
> existing DSP code to use it, because it has to be aware of the event
> model.
>
It should be easy to write a compatibility plugin that calls plugins
without event handling. The reverse is not true...
// Pseudocode...
compatibilityPlugin(..., event)
current = 0;
for(full range)
{
partSize = nextEvent - current;
plugin->process(..., current, partSize);
plugin->processEvent(event);
current = nextEvent;
engineGetNextEvent(plugin, event) // the last event is not removed
}
> By contrast, if we adopted this model, we could adopt, for example,
> all or many of the Csound opcodes with "very little" effort. They all
> currently rely on a global called nsmps. "All" we'd have to do to use
> them would be to make nsmps the name of the buffer size argument (as
> declared in their source), and presto - they'd do the right thing. Of
> course, in reality, there would be more to it than that, but not
> much. I imagine that many other examples of DSP code could be used in
> a similar way.
>
> --p
--The Internet interprets Windows as damage, and routes around it.
Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST