Subject: Re: [linux-audio-dev] API design again
From: David Olofson (audiality_AT_swipnet.se)
Date: to loka 07 1999 - 17:36:15 EDT
On Thu, 07 Oct 1999, Paul Barton-Davis wrote:
> >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)
>
> This is a very valid concern. I was trying to find an example of where
> the varying frame count would cause problems - this is a good
> one. Anyone else have comments on FFT (or other algorithms) and the
> problems that variable frame counts might cause ?
Here's one: How to keep track of the buffers used to connect the plug-ins?
Could be done using circular buffers and either coping some data to get full
buffers at the wraps, or... breaking buffers that are split into two calls.
The next issue is related to the one above: How to control the plug-in
execution order? Either an fixed "official" buffer size is needed (which means
*required* buffer splits at a fixed interval; any event that happens to not
hit a fixed split will result in an extra split) - or full *dynamic* dependency
resolution for the entire processing net. (I tried to design such a beast - and
gave up. Maybe I missed something, but I think it's too expensive, no matter how
it's realized.)
> >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
> >}
>
> Excellent example. The question remains: should this be the
> responsibility of the plugin or the engine ? Do you really want
> *every* plugin derived from non-event-based code to contain this kind
> of wrapper ? Doesn't it remove most of the benefits of the approach ?
No. Inline plugin.processEvent(), and you're pretty close to the performance of
a "real" plug-in. Then you can start to move things around if you like...
True, porting back to the old API, or using the same code base may not be as
nice as it could be... But OTOH, this problem will show up in *some* cases, no
matter which model we chose.
And finally; are we designing a Universal Plug-in Compatibility Layer, or a
real, flexible, efficient and powerful plug-in API? Let's not build in legacy
stuff right from the start... (Ok, it might turn out that dropping the events
out of the process() call isn't just a backwards compatibility hack, but I
still see more problems with that, than with the "all into process()" model in
the bigger perspective.)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST