Subject: Re: [linux-audio-dev] MuCoS: New "radical" changes!
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti loka 19 1999 - 01:18:02 EDT
>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! although i
don't quite see how it can work. what does the event mean ?
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.
my vision of this: a buffer gets one or more input buffers which it
can't touch (const unsigned char * const :). if it needs any internal
buffers, they are allocated at init time, and whenever the engine
broadcasts a buffer size change event (both hugely expensive events
any way you measure them). 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 ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST