Subject: Re: [linux-audio-dev] MuCoS: New "radical" changes!
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka 19 1999 - 01:04:03 EDT
On Tue, 19 Oct 1999, Paul Barton-Davis wrote:
> >1) Have a "new buffer for channel X starts now" event, and
> > just handle it as usual in process(). (Possibly, the
> > event can handle multiple channels - a performance hack
> > for the average case.)
> >
> >2) Make the engine insert those events when needed - in the
> > normal case; first in the event input buffer.
> >
> >3) Have fun!
>
> what makes you think I wouldn't like this ? i love it!
Just a joke related to the Gregory Bateson inspired post; events vs.
streams. :-)
> although i
> don't quite see how it can work. what does the event mean ?
The event means that the timestamp is where to stop processing and
handle the event (as always), and that event carries the pointer to
the next buffer for a certain channel. That is, you handle the event
by grabbing the pointer, possibly resetting the index variable for
that channel (unless you increment the pointer), and then go back to
processing until there time of the next event.
The total number of samples to process during the call can be passed
through the first event in the buffer or a terminator event - the
latter probably being the least expensive for the plugin, while the
former avoids the engine having to traverse the event list to find
out where to insert that terminator...
> also, i still don't see any need for a particularly fancy scheme for
> handling buffer allocation. its so rare, and they are so long-lived
> and so intimately connected with the construction of the processing
> net that all of your usual RT-concerns don't seem to apply here.
A LIFO stack (ar call it a pool) of equally sized buffers that the
engine can grab when it needs them. Minimum memory use, maximum
simplicity, and good cache optimization. And with the "new buffer"
approach, it still works if you need dynamic rate streaming.
> my vision of this: a buffer gets one or more input buffers which it
> can't touch (const unsigned char * const :).
Why not just forget about reserved buffers altogether (except for
private buffers that plugins may need), and grab them from the pool as
needed? The cache will love it! :-)
> if it needs any internal
> buffers, they are allocated at init time,
Yes. Most plugins will probably be capable of estimating the maximum
buffer size they need. If not, perhaps they should have access to the
buffer pool? I don't really like the idea, but perhaps it can be kept
clean... (Think "variable delay" - the buffer size must cover the
maximum delay. That can be a lot of RAM.)
> and whenever the engine
> broadcasts a buffer size change event (both hugely expensive events
> any way you measure them).
That depends entirely on the engine with the new little idea. The
plug-ins just do as they're told, just as before, with the one
exception that you have to be smart about "new buffer" events if
you're about to ignore the timestamps. But you shouldn't really do
that anyway...
> it additively writes to its output
> buffer(s). the input buffer(s) and output buffer(s) are shared across
> all plugins and are "owned" by an (audio...) input thread/client and
> an (audio ...) output thread/client. we're done. where does all this
> need for careful buffer allocation come into play ?
Well, it doesn't, unless true variable buffer size is needed. :-)
Strings and that kind of things is still a problem, though...
//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:59 EST