Re: [linux-audio-dev] API design again [code]

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

Subject: Re: [linux-audio-dev] API design again [code]
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka   09 1999 - 15:11:16 EDT


On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> where do the events come from ?

Always from within the same thread.

> that is to say, in a multi-threaded
> system, what actually allocates, deallocates, and otherwise sets up
> event_t's for their use in the API ?

This low level part of the API is only intended for building the event buffers
to pass on to other threads. (As opposed to transmitting events one at a time.)

> if its the engine thread itself, how do you get events delivered to
> it? i see two possibilities, both of them bad.
>
> 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.

> In the case of GUI stuff, its
> even worse, since at least one well known and widely utilized GUI
> system (X Window) isn't (properly) multithreaded, and you will crash.

Same rule applies. It's up to the GUI system or the application's GUI code to
grab timing infromation.

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

> So, it seems likely to me that we're going to need to be able get hold
> of event_t's from multiple threads. In that case, how do you ensure
> atomicity on the *next pointer, and on *heap ?

(See above.)

> if qm_thread_t is actually as simple as you propose, you can't use
> lock free queues, and likewise for the event_t *next pointer.

There *is* one related problem here. In cases where the sender and
destination is sharing physical memory, the qm_new_buffer() function (that gets
called when some qm_heap_t runs out of buffer space) needs to get new buffers
from the global (shared) heap.

One solution would be to have individual "global" heaps for the threads that
need to get buffers from a certain shared memory block, and then have some kind
of "daemon" to move buffers around to keep the system in balance. However, that
gets a little unreliable when low on memory.

The clean and simple solution is to have the qm_new_buffer() function in kernel
context, as an ioctl() of the Multimedia Communication Core, and protect the
global memory heap with a spinlock.

> so somewhere in there you're going to have one or more locks that need
> to be taken, and the cost of this will far outweigh the other stuff
> you're worried about.

There will be a spinlock for the operation of the Multimedia Communication Core
grabbing all new buffers for merging and/or passing to the local (real)
destination ports. It will contend for the duration of a few instructions when
an application is so late finnishing it's cycle that it hits the lock just
when the engine is about to gather the input for the next cycle... (That's an
overload condition.)

> or have i missed something fundamental and obvious again ? :)

Fundamental, but not obvious. :-)

//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:13 EST