[linux-audio-dev] Some Event stuff for now...

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

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


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:27:12 EST