Subject: Re: [linux-audio-dev] API design again
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka 09 1999 - 15:52:12 EDT
On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> a plugin will almost never be just a function call. it will have some
> state that goes with it. the other callback "process_events()"
> understands how to parse the events and manipulate the state data.
Ok. Still two function calls for every single bunch of "simultaneous" events,
as opposed to one call for a fixed number of samples.
> one thing i prefer about this approach is that it enforces cleaner
> conceptual thinking on the part of a plugin designer.
Enforcing a certain way of thinking 1) upsets many developers and 2) still
doesn't keep sloppy programmers from hacking bad code. Hopefully, it improves
things a bit in some cases, but "evil" programmers tend to work around the
implied style anyway for various reasons...
> the process()
> call is responsible for generating data on the basis of the current
> state and the amount of data called for; the process_events() call is
> responsible for mapping from the event types floating around in the
> system to the internal state of the plugin.
>
> this seems like a big win to me.
It is, but what's the big difference from making the real_process() function an
inline and "call" it yourself from within the process_with_events() function's
decoding loop?
All you have to do is check the time stamps... (Or don't, if you don't care
about sub-buffer size accuracy. Or quantize to 4 samples, if that fits your
real_process() better.)
//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