[linux-audio-dev] threading in DSSI plugins

[Florian Schmidt]

On Wed, 10 Aug 2005 14:09:55 +0200
Alfons Adriaensen <fons.adriaensen at alcatel.be> wrote:

Hi,

thanks for your answer.

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

Right.

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

Yep..

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

I plan to have two modes. 

a] 0 - latency, where Partitionsize == periodsize and without any extra
buffering, etc.. This is practically zero latency but with the expected
cpu usage.

b] buffered/threaded - where Partitionsize > periodsize, and the
buffering/threading scheme we talk about here is used.

The case where periodsize is > partition_size is really not common i'd
reckon. The user could use the 0 - latency mode here.

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

Sounds good. Thanks for the info.

Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org