Subject: Re: [linux-audio-dev] API design again [code]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la loka 09 1999 - 16:20:38 EDT
>> 2) h/w-driven events get noticed by other threads, and are then
>> delivered to the engine thread somehow. this seems to imply some
>> wholly different event-type-specific-API. seems like a bad idea,
>> given that this event system is supposed to be generic.
>This is closer to my solution. However, the physical event_port_t
>instance you see from your thread is not the same one as the actual
>destination. (Unless the destination is running in the same thread.)
it can't be, by my very definition: the engine thread is where plugins
run, and other threads are what wakeup from select(2) in order to
generate an event_t.
>It's a "shadow port" that's only used to hide the fact that you're
>working on your own, in your own context, all the time until you're
>done with all work related to the current cycle. It's not until then
>that the event buffers will be sent off to their real destinations.
this still seems unclear to me. suppose i am a MIDI input thread, and
I wake up from select(2). i read the available data. what do i do now?
how do I generate an event_t that can be inserted into the relevant
queues passed to plugins ?
Turning to the first approach, you commented:
>> 1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
>> events, etc) get handled by a plugin run by the engine thread.
>> In the case of MIDI-like stuff, this gets rid of sample accuracy,
>> since we can't notice the event till we execute the plugin, which
>> happens once per control cycle.
>Implementation flaw. You will always need an IRQ handler or a separate thread
>to add timing info, if the hardware doesn't.
but add it to what ? what is the data structure that the timing
information gets marked in ? device drivers that manage byte streams
don't read/write structures, so it can't be part of the data stream
from the driver. it can't be an event_t, since the thread that handles
the h/w event can't allocate event_t's without a lock. so what it is
that gets timestamped ?
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST