Re: [Linuxsampler-devel] Event system

[David O. <da...@ol...>]

On Sunday 09 November 2003 01.31, Christian Schoenebeck wrote:
[...]
> Ok, for things like EGs where undeterministic factors are involved
> I share your opinion better not to let them prequeue their events,
> but I'm thinking about the sequencer scenario where the sequencer
> might want to prequeue events somewhere past the scrope of the
> current frame. I'm not sure if there's already something like that
> (sequencer / protocol). Don't you think that would be a pro for
> not-frame-relative events?

Well, in the case of Audiality, normal plugins just won't care about=20
input events past the end of the buffer cycle, so you *could*=20
prequeue without causing any trouble, that far.

(Actually, there is a minor issue with big gaps and wrapping=20
timestamps, but that's just because I use 16 bit wrapping timestamps.=20
No need for more, as long as the "one buffer at a time" rule is=20
obeyed.)

However, if you really want the prequeueing to be of any real use, you=20
have to allow some plugins to look ahead on the input as well - or=20
you're still limited by the same issue as always: You do not know=20
about the future (which is defined by future input events), and thus,=20
you cannot prequeue output events.

For example, if you let the sequencer prequeue, you've effectively=20
forwarded the timing part of sequencing to whatever receives the=20
events, instead of just processing one buffer cycle at a time. (Note=20
that this can potentially mean that the sequencer causes CPU load=20
peaks potential event pool drain, when it occasionally prequeues new=20
events!) That *could* perhaps allow EGs to save some cycles by not=20
running every buffer cycle - but then the EGs have to *know* whether=20
or not they're allowed to work outside the current buffer cycle, or=20
they will not function properly with "live" input.


> > (In Audiality, I do have a sorting "insert" operation, though
> > it's not used, and probably never will be. XAP wasn't even meant
> > to have such a thing. Events are always required to be sent in
> > timestamp order.
>
> But what if you're using an UDP based protocol? That might mix the
> events.

That's something the "gateway" to the outside world will have to deal=20
with. This kind of event system is based on the idea that events are=20
just a form of structured audio rate data, which differs quite a bit=20
from QNX style message passing, UDP, GUI toolkit event systems and=20
the like.

Basically, if you can maintain a fixed rate audio stream, you can also=20
transmit an Audiality/XAP style event stream. If you have drop-outs=20
and similar issues, both audio and event streams will need to be=20
"repaired" one way or another before going into a plugin net.

This may seem restrictive if you consider only plain events, but if=20
you consider ramp events, you'll realize that anything else would=20
make life quite a bit harder for event receivers. Overlapping ramp=20
sections, gaps etc, and you'd have to take special measures to avoid=20
clicks, that are not necessary otherwise. An extra layer of zipper=20
noise protection, that belongs in the soft/hard RT gateway; not=20
inside every plugin.


> > The addressing and routing system ensures that multiple event
> > streams to the same input get sort/merged properly, and without
> > cost for 1->1 connections.)
>
> You mean no need for sorting events that are dedicated for
> different purposes anyway, right?

Actually, it doesn't matter what the events are for, since they still=20
have to be in timestamp order if they go to the same physical input=20
queue. Decoding is normally driven by the event stream, like this:

=09while(samples_left_to_process())
=09{
=09=09while(time_to_next_event() =3D=3D 0)
=09=09{
=09=09=09process_event();
=09=09}
=09=09samples =3D time_to_next_event();
=09=09if(samples > samples_left_to_process())
=09=09=09samples =3D samples_left_to_process();
=09=09process(samples);
=09}


> Would it make sense to have
> individual queues for some special purposes (to avoid mixing things
> and thus reduce time complexity)?

Definitely, and that was designed into the XAP event system, be means=20
of "context IDs" of control ins and outs.

A plugin with multiple "inner" loops (like a mixer processing one=20
channel at a time) would have separate event queues (thus controls=20
with different context IDs), and the only ordering that matters is=20
that within a queue. No sort/merging needed if there's one sender (ie=20
one loop generating ordered events) for each queue, or if one sender=20
sends to multiple queues.

A host detects the need for a sort/merge object by checking for=20
multiple output contexts sending to a single input context. That is,=20
sort/merge is *only* done if two "inner loops" are sending events to=20
the same physical event queue.

A plugin developer can organize things any way he/she sees fit, and=20
then just slap context IDs onto controls according to their relations=20
to the internal loops of the plugin.


> > Now, those of you who actually read all the way here are probably
> > at least as obsessed with event systems as I am. We should all
> > consider getting a life! ;-)
>
> Just a matter of multi tasking... [switch]

Still, there are only so many cycles in a day. :-)


> > `-----------------------------------> http://audiality.org -'
> >    --- http://olofson.net --- http://www.reologica.se ---
>
> I like the Requirements for Audiality ("Reasonably new C compiler",
> "An operating system", "Sound card with drivers").  :)

Keeps the volume of email from people trying to compile Kobo Deluxe=20
(which uses Audiality) really rather low. There was some gcc 3.x type=20
casting issue somewhere, and I discovered that you need a macro to=20
copy a va_list on PPC, but that's about it. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---