Subject: [linux-audio-dev] Some Event stuff for now...
From: David Olofson (audiality_AT_swipnet.se)
Date: ti syys 21 1999 - 20:26:14 EDT
Hi...
Here's a part of the current version of my Event System proposal. I think the
stuff I'm building around this will be more interesting, but I really have to
get some sleep now, so this will have to do for now... Hope you get the idea.
Perhaps I should point out that I intend to use an optimized memory allocation
system with allocation + "flush all" operations per heap buffer only. There
will be no dealocation, and no fragmentation. (The engine/plug-in host is
responsible for setting up heaps for sub-nets, so that it can flush them once
per buffer period, or whatever fits the scheduling algorithm.) The heap
definition will be a public structure + macros/inlines for performance, and
should be viewed more like an output buffer on steroids than a real memory
manager.
The reason for using arrays of pointers rather than just events as raw data
written sequentially into the output buffer is on the engine side - merging of
events from multiple sources etc...
/*
* The engine encode time stamps as samples from
* start of the timing master buffer, which can be
* selected by the plug-in.
* (Alternatively, this could be a float, but I
* think that should be optional for performance
* reasons.)
*/
typedef unsigned int event_time_t;
/* For efficient decoding, events are grouped as
* system, control, gui, custom etc... (Custom is
* a group that's reserved for private talk between
* GUI and process() code, and should *not* be used
* for anything that could make sense to use standard
* events for.)
*
* The EV_FLAGS field is used for telling requests
* from replies and that kind of things.
*
* EV_KIND is the actual event code. Event kinds
* should be declared as enums for good optimization
* possibilities in switch() decoding. (That's why
* there's a CLASS field.)
*/
typedef unsigned int event_code_t;
#define EV_CLASS_MASK 0xff000000 /* TIMING, SYSTEM, CONTROL,... */
#define EV_FLAGS_MASK 0x00ff0000 /* EVENT, REQUEST, REPLY... */
#define EV_KIND_MASK 0x0000ffff /* Exactly what event is this? */
struct event_t;
struct event_port_t {
int events; /* Number of events currently in the buffer */
int maxevents; /* Size of the buffer */
event_t **buffer;
};
struct event_t {
event_time_t time;
event_code_t code; /* What is this? */
/* This 'from' field being a pointer to the
* Event Port struct of the sender might be
* a bit dangerous. (I'm thinking Event Port
* lifetime...)
*/
event_port_t *from; /* Who is this from? */
int size; /* Number of data bytes */
};
(event_t is of course just the header - any number of bytes of data may follow.)
Any ideas about the from field? What I mean is, a simple way of making sure that
no one tries to reply to an event from a port that was just removed? (I think
it'll become clear when dealing with the life time of event buffers. When all
buffers with events from a certain port have been flushed, it's safe to delete
the port - unless some plug-in decides to remember a reply port address for
later use... That should probably not be allowed.)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST