On Wed, 10 Aug 2005 14:09:55 +0200 Alfons Adriaensen <[EMAIL PROTECTED]> 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
