Subject: [linux-audio-dev] EVO event handling proposal ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Jul 21 2000 - 14:35:32 EEST
Hi, I just sketched out a way to keep the innermost audio rendering loop small
and lean even in the presence of many event.
I'd like to hear comments about this approach and if a better one exists:
at note-on time I do:
for each paramenter (volume,pitch,etc) {
- load the envelope data ( current_value ,delta)
- check if this parameter arrives before the others, if yes set
next_event_numsamples to the numsamples (eg the current volume envelope len)
and insert the appropriate parameter loading function (current_value, delta)
in to the PARAMETER-HANDLING function array
at this point all parameter envelopes are loaded, and
next_eventsamples contains within how many samples the next (earliest) event
occurs (and the paramenter-handling functionptr array contains the actions to
be taken when this occurs)
now , let's say the audio rendering routine does the following:
for each sample {
if(--next_event_numsamples <= 0) {
-call the all parameter handling functions (most of time this will be only
one, except when more than one event occurs within the same sample)
- this will in the case of the volume parameter , load the new volume
envelope table (curr_value, delta)
-fow for each parameter check what the next occurring event will be
set next_event_numsamples and the function ponter array accodingly
}
calculate new sample and and write result to output buffer
}
notice that the if(--next_event_numsamples <= 0) will be triggered relatively
rarely if you avoid to build sample-per-sample envelopes
and the --next_event_numsamples operation will be almost negligible
compared to the new sample computation (which will involve interpolation,
amplitude modulation and filtering)
We could do an additional optimization like:
if( next_event_samples > num_samples_per_fragment) then
use a routine without the
if(--next_event_numsamples <= 0)
and decrement next_event_numsamples by num_samples_per_fragment
at the end of the loop.
But I guess this optimization buys us close to nothing.
comments , more efficent designs , flaws of this model ?
( David you are the Mucos event expert, what do you think ?)
Benno.
This archive was generated by hypermail 2b28 : Fri Jul 21 2000 - 15:31:38 EEST