[linux-audio-dev] threading in DSSI plugins

[Florian Schmidt]

On Wed, 10 Aug 2005 12:01:17 +0200
Alfons Adriaensen <fons.adriaensen at alcatel.be> wrote:

> On Wed, Aug 10, 2005 at 11:34:39AM +0200, Florian Schmidt wrote:
> 
> > a] is it possible to use threading in a DSSI?
> 
> I've done this in some LADSPAs, it works. 

Great..

> 
> > b] would a RT prio of 1 (for the convolution thread) be an OK
> > compromise? It will be lower than all audio stuff on a typical jack
> > system? What is jackd's default RT prio again?
> 
> When running in JACK, you can obtain JACKS thread id and then
> look up its priority. Otherwise, you can query the thread's prio
> the first time your process() is called and then create a thread
> just below it.

Great tips. Thanks.

> > [2] - yes, i'm aware that this needs again some extra buffering ;)
> 
> It doesn't need to: the extra buffering can be absorbed into the
> buffers you need anyway - zero overhead. I've got a C++ implementation
> of this, just drop me a line if you want it.

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
- important to keep in mind) and the internal partitionsize of the
convolution is 2048 frames. Let's further assume the convolution thing
has internal input and output buffers of 2048 frames each. The input
buffer is initially empty and the output buffer is initially full
(filled with 0's)

- run() 1: 1024 frames are filled into the input buffer. Also 1024
frames are output from the output buffer

- run() 2: 1024 frames are filled into the input buffer and 1024 frames
are consumed from the output buffer. The input buffer is now full and
the output buffer empty. We have enough data now to do tha thang. So we
somehow (how? [1]) communicate to the convolution thread that it should
start to do process the input buffer now. We don't know yet when it will
finish, but to meet any sort of deadline it should finish before another
2048 frames have arrived.

- run() 3: 1024 frames are filled into the input buffer -> ouch. The
input buffer is what the convolution thread operates on right now. 1024
frames are consumed from the output buffer -> ouch, it's empty, plus
this is where the convolution thread puts its output.

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. 

Damn, need to run to university now. I'll read up lateron..

Flo

[1] - the typical
      rt-safe-kicking-off-another-thread-to-do-something-problem raises
      its ugly head again. What other options are there? sleeping for short 
      intervals and lay down again when nothing to do?

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