[linux-audio-user] Re: [Jackit-devel] Re: [linux-audio-dev] [ANNOUNCE] jack_convolve-0.0.1 - Linux-audio-user

30 Jan 2005

Fons Adriaensen &lt;fons.adriaensen(a)skynet.be&gt; writes:

...
  On Sun, Jan 30, 2005 at 10:23:29AM -0600, Jack
O'Quin wrote:

  One simple improvement I'd recommend.  JAMin
runs its DSP thread at a
 RT priority one less than the JACK process thread.  It would be better
 to add (log2(bufsize)-log2(chunksize)) to the JACK priority (only when
 negative).  Then, multiple JACK client helper threads could share RT
 scheduling cooperatively, so the ones with lower scheduling deadlines
 get to run first.  I think that works for any collection of sizes,
 assuming the total CPU bandwidth is sufficient. 
 That would certainly help in the case you decribe, but ISTR (should
 search for my notes from previous lifes), there is a limit of about
 70% CPU load where such a scheme will break down. It's probably 
 quite hard to improve on this with fixed priorities.  
True, but in many cases 70% isn't bad.

...
  IIRC, the reason it breaks down well before 100% load
is that the
 priorities should really be a dynamic function of how far the
 deadline actually is at any time, rather than being fixed.
 For example, a calculation for a relative chunk size of 8 that has
 one period left is more urgent than one for a size 4 chunk that
 still has three periods until its deadline. 
Right.  I haven't done the math, but my intuition is that in the
special case of JACK clients and various larger power-of-two chunk
sizes, this scheme should work very well.  Maybe even optimally.

...
  To avoid this limit, the work should be divided evenly
over the
 periods that are available to do it, and in that case you don't
 even need a second thread. But that's probably very hard.  
Sure.  

In the case of JAMin it was dictated by our desire to use FFTW rather
than writing our own FFT and trying to figure out how to divide the
computation into relatively equal parts.
-- 
  joq