Subject: [linux-audio-dev] API design again
From: Guenter Geiger (geiger_AT_epy.co.at)
Date: ke loka 06 1999 - 09:28:30 EDT
Paul Barton-Davis writes:
> I'd like to hear Gunter and David discuss the issue of varying the
> process() "sample count argument" again.
>
Actually I didn't discuss it that much but ...
... digging in the archives .....
Davids code:
------------------------------------------------------------------------
process(...**inputs, ...**outputs, ...**events, samples)
{
int current_sample = 0;
int current_event = 0;
int count;
while(current_sample < samples) {
/* process until next event should take effect */
count = event[current_event]->time - current_sample;
current_sample = [current_event]->time;
while(count--) {
process one sample;
}
/* handle event... */
.
.
.
}
}
-----------------------------------------------------------------------
as opposed to the other (Benno/Paul) proposal (which does basically the same):
-----------------------------------------------------------------------
event_time=event.time; (in samples)
samples_before_event=actual_time-event_time;
rest_samples=samples_per_buffer=samples_before_event;
pluginobj->process(inputs,outputs,samples_before_event)
process the event (change parameters etc)
pluginobj->process(inputs,outputs,samples_after_event);
----------------------------------------------------------------------
Under the assumption, that events occur on a basis smaller than
the processing blocksize, this is equally fast as fixed buffers,
but with sample accuracy.
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.
Guenter
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST