Re: [linux-audio-dev] Problems and Solutions: events v. signals

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Problems and Solutions: events v. signals
From: David Olofson (audiality_AT_swipnet.se)
Date: ti tammi  11 2000 - 20:37:03 EST


On Sun, 09 Jan 2000, Roger Larsson wrote:
> (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.

It has to handle signals and events differently, no matter the API.
Signals are pointers into "endless" arrays of data, and my "new
buffer pointer" events are used to move the pointers around to keep
the plugin or client reading and writing in the right places.

> 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.

IMHO, an event tells something about an "unusual" change, while a
signal is a continous stream of samples, approximating a continous
signal. You never know when you're going to receive an event (unless
you peek in the buffer ;-), but you do know that there is signal data
to process on all channels until the time of the next event.

> 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 :-)

Cool in theory, but there are some serious problems IRL...

> 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.

...and these time formats have to be handled, by hosts as well
plugins and clients. Great fun having to keep track of N signals that
can assume any sample rate the engine considers suitable, right? :-)

> 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}

Who tells you that the signal has changed it's rate? Do you have to
check all ports on every call to find out?

And the engine has to generate lots of data just to get that one
control signal change in the right place. And what about two
changes, or three? That requires the signal sample rate to be the
lowest common denominator of the change times...

> * event/signal queue gains by sorting it in variable# as first key.
> Times are always deltas - not sorted explicitly. Arrive sorted!

This is no different from my system; you are required to send events
in order, and the timestamps are taken in account when merging
events from multiple sources for a plugin or client.

> * The plugin _may_ chose different implementation depending on input
> 'times'.

Is that a runtime choice, or what exactly are you referring to
here...?

> * Several outputs can not be connected to one input can not be connected
> directly.

This is good from the engine POV, but it does mean that plugins get
multiple input ports. That situation is a complexity nightmare right
where things should be kept simple, especially if these ports can
have different sample rates.

> * One output can be connected to several inputs.

Good - no data copying.

> Remaining problems:
> Will be expensive to check every fragment if there are
> lots of channels/signals...

Yep, very expensive, I'm afraid. Some smart optimization will be
needed just to find out which channels to check in the start of each
plugin call, or client "cycle".

//David

.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST