Subject: [linux-audio-dev] Problems and Solutions: events v. signals
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: la tammi 08 2000 - 21:39:05 EST
(David, you have received another one - delete that one)
Problem: events and signals are treated in different ways. Events may
update signal buffer locations (as suggested). But a plugin have to
handle events and signals in different ways.
Observation:
What is the difference between a signal and an event?
Not much!
Events happens rarely.
There might be a lot more event destinations than signal/connectors.
Solution:
All events can be treated as an input signal with per fragment varying
sample rate, if everything that an event might change are assigned to
a signal/connector of its own.
This way all parameters used by a plugin may be a signals too :-)
normal signal event chain:
{timeN, signal#A, *buffA1} {timeN+time(buffA1), signal#A,*buffA2}
event, parameter change, signal chain:
{timeM, param#P, value1} {timeN, param#P, value2}
If 'time' is treated as described earlier in "P&S: time" there is no
longer any need to distinguish between signals and parameters. They get
with different time formats.
Note:
* a signal that is event driven. Can normally be driven with a constant.
and only during fragments where something happens it changes to a
sampled
signal format. (even if sampled all the time)
{durationA1, variable#A, *buffA1} {durationA2, variable#A,*buffA2}
* event/signal queue gains by sorting it in variable# as first key.
Times are always deltas - not sorted explicitly. Arrive sorted!
* The plugin _may_ chose different implementation depending on input
'times'.
* Several outputs can not be connected to one input can not be connected
directly.
* One output can be connected to several inputs.
Remaining problems:
Will be expensive to check every fragment if there are
lots of channels/signals...
/RogerL
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST