[linux-audio-dev] threading in DSSI plugins

Florian Schmidt mista.tapas at gmx.net
Wed Aug 10 09:34:39 UTC 2005


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?

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!

More information about the Linux-audio-dev mailing list