[linux-audio-dev] threading in DSSI plugins

From: Florian Schmidt <mista.tapas@email-addr-hidden>
Date: Wed Aug 10 2005 - 12:34:39 EEST

Hi,

i played around with extra buffering the input/output of libconvolve
(new tarball [1] and updated jack_convolve [1] (understands the
--partitionsize=frames argument now which makes it use the specified size
for the partition size instead of the jack buffersize), and like
expected this doesn't do CPU usage any good.

Easy to see in this example:

jack_buffersize = 1024

partitionsize = 2048

Now the convolution code is executed only every second jack process()
cycle. If the previous DSP usage was like 20% in every process cycle
then it's ca. 25% in every other cycle now (estimate).

The solution to even out the load is to use an extra thread [2].

For best performance i would assume that the DSSI needs an extra thread
with RT scheduling (if available) and an RT prio which should be lower
than all the other jack and midi threads of i.e. the DSSI host and other
jack clients.

So i got basically two questions:

a] is it possible to use threading in a DSSI?

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?

Regards,
Flo [3]

[1] - http://tapas.affenbande.org/?page_id=5

[2] - yes, i'm aware that this needs again some extra buffering ;) But
this whole larger-partitionsize-than-jack-buffersize-thing is all about
trading latency for cpu niceness. If the convolution is used as non RT
effect [like i.e. in a DAW for prerecorded material], then latency
doesn't matter as long as the host compensates for it.

[3] - i'll probably be offline from the 12th on, as i can't pay my phone
      bill, so be quick with answers ;)

-- 
Palimm Palimm!
http://tapas.affenbande.org
Received on Wed Aug 10 16:15:05 2005

This archive was generated by hypermail 2.1.8 : Wed Aug 10 2005 - 16:15:06 EEST