30 Jan
2005
30 Jan
'05
7:51 p.m.
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.
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.
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.
--
FA