Subject: Re: [linux-audio-dev] API design again [code]
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka 09 1999 - 20:52:03 EDT
On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> So the event is now queued in my local event port. What causes it to
> become available to the engine, and thus get delivered to the plugins?
The one sync point that your malicious example is trying to avoid! ;-)
At some point, you have to tell the engine to "grab" the new events,
and that will need to be a sync point of some kind... possibly a FIFO
where the address of the "news" (first event in a linked list, or
whatever it'll be in the end) is passed.
In the case of audio streaming, the natural sync point is the end of
the buffer cycle, and your thread will sleep there, or on the start
of the cycle, if the client gets data from the engine as well.
One possible solution is that your thread wakes up on the
client/server port as well (an ioctl or something - will be a part of
the API anyway), just to keep in sync with the engine's cycle time.
That way, you can get the lowest possible latency without having to
send events to the engine as soon as they come in.
> >Regarding the flushing of the heap buffers you use: As you don't have cycles,
> >there will be no natural interval for sending the current buffer off to the
> >garbage collector for the context of the event port. What will happen is just
> >that the buffers will be left around, and you'll implicitly pass them to the
> >garbage collector when they're full.
>
> >(Note: "Sending to the garbage collector" is a bit simplified. A buffer will
> >first move to the "queue of buffers to be used" of the real destination event
> >port. From there, the buffer is returned to the global heap when it's been
> >parsed by the destination plug-in or client, and is no longer needed.)
>
> ah. now we get more complex still ... how can the plugin or client
> possibly do this without a spinlock ?
There will be the global heap spinlock... Of course, some FIFO
approach could be taken, but I doubt it's worth the effort. (One
FIFO per thread; when out of buffers, qm_new_buffer() checks one
FIFO at a time until it finds some buffers...)
//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:13 EST