10 Aug
2005
10 Aug
'05
10:09 a.m.
On Wed, Aug 10, 2005 at 12:28:01PM +0200, Florian Schmidt wrote:
Let's play this through with an example. For
simplicity's sake let's
assume the host always calls the plugins run() method with a constant
buffersize of 1024 frames (there's still no requirement for this though
...
Sorry, I didn't express myself correctly. There is indeed more delay,
but what I'd wanted to say is: there is no need for copying your signal
into one more layer of intermediate buffers.
The problem i see should be clear now. The solution i
would use would be
to make both input and output buffers twice the partition size (you can
probably fill in the blanks :). I have also ignored the remaining
synchronization issues.
For th input you could use two buffers of the FFT size each. When one is
half full, you hand it over to the lower priority thread and start using
the other. Or you could use just one and do the forward FFT on the input
in the original thread. This will probably be just a small part of the
total work to be done for that input, so it should work, but will give
an somewhat uneven load as seen from the caller.
On output you probably already have a circular buffer to keep the
partial results in between processing calls for one partition. If you
make it one partition size longer than what it would normally be,
and set the initial output pointer one partition size before the end,
there is no need to make extra copies.
The result of this all is that if period_size >= partition_size, you
have one more partition delay than strictly necessary. In that case
just advance the initial output pointer to the start of the circular
buffer.
For synchronisation, you need to wake up the worker thread somehow
when a partition of input is available. A Posix sema or condition
variable will do. Assuming the system is not overloaded, there is
no need to sync in the other direction - just assume that your
worker thread has done its job and read the results.
--
FA