Subject: Re: [linux-audio-dev] API design again
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la loka 09 1999 - 16:30:11 EDT
>> 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?
its extremely unlikely to be coded inline except by the truly
fanatical writers of the smallest plugin imaginable. if compiled with
-fomit-frame-pointer, the cost of a function call pails compared to
the register optimization possibilities that open up for the compiler
as a result of it having its own frame.
>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.)
i think i am persuaded. this changes the "model" of what the core
plugin function call does so that event processing is the core task,
and data processing/generation is the secondary one. subtle, but
possibly important.
we still need to clear up the thread issues in my previous email.
--p
ps. if you use emacs, could you set your fill-column to something
around 70-74 ? your mail invariably ends up with lines longer than 80
chars when its gets quoted even once, and i end up reformatting it
every time. thanks.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST