[linux-audio-dev] Re: 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] Re: Some Event stuff for now...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke syys   22 1999 - 17:45:05 EDT


On Wed, 22 Sep 1999, David Olofson wrote:
> 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.

David,
I'm still missing a clear picture of the event buffer.
David, you say that you want to flush the buffer on each buffer period.
Do you plan to use per-plugin event buffers ?
Sorry if I dont understand this, but I often have to think in terms of pratical
examples.

Assume a simple sampler-plugin:
input: MIDI NoteOn / NoteOff events (to specify triggering and pitch)
output: sample-stream in float format

assume that there are 2 sequencers bombarding the poor sampler-plugin
with Note-on events.
Of course you want to allow timestamped events, therefore the plugin has to
schedule to events in right order.
When do you know to free the buffers ?
You said "flushing on the next buffer period", but what if the timestamped
event has to be scheduled several periods later.
Do you need an additional buffer to queue up timestamped events ?

Ok, you can advance the heap pointer for non-timestamped data, but
for timed events you have to take an other buffer flushing mechanis.
But since David does have a diabolic mind, he has already solved this issue.
:-)

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

Ok, but these pointer have to point so some useful data, and you must
alloc/free the data at some point, and this must be implemented using fast
routines.
Again in the case of timestamped events you have to pay attention when
to free the structs.
Or is this problem already solved ?

>
> /*
> * 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.)

Yes, but what if the samplerate changes ?
Or will the API provide a fuction like
event_time=time_2_event_time(float time) time in secs with fracions, or maybe
struct tv like

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

what is exactly an event_port ?
A place where you can send events ?
in the sample-player-plugin case:
it the input-port of the plugin where you send the MIDI events ?

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

What about to require the event-senders to notify the event-receivers
that they want to exit ?
Maybe we could use double indirection:
the **from is a pointer to a function pointer which gets the real from address.
This function pointer arrays could be static (maybe with some garbage collection
for reallocation).
Therefore if an event-sender wants to exit, then it should just set the *from
address to a fake port which is called NO_PORT or so,
therefore in the case that the event-receiver wants to query data about the
event-sender, there will be a function which will return PORT_NOT_PRESENT (=
plugin exited or so),
with no crashes due to inexistent pointer deferences etc.
And since the port-pointer will take only 4 bytes, even with a very lazy
allocation/garbage collection scheme we will not run out of memory too soon.
:-)

Opinions ?

Benno.


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