[linux-audio-dev] another kernel patch?

[Jack O'Quin]

Roger Larsson <roger.larsson at norran.net> writes:

> If next client is a RT process (SCHED_FIFO/RR) then it WILL be selected
> unless there is another RT process with higher priority, and lower than jackd
> otherwice it would have been running in the first place.

I wish this were the true.  But, I strongly suspect that it is not.

> > however, for some bizarre reason, the scheduler does not in fact run the
> > next client, but does something else instead.
> 
> If this ever happens (and something else is not within in the priority range
> new process ... jackd) then it is a scheduler BUG - and should be fixed!

That's right.  But, Paul and I have been working closely with this and
don't have much faith in the correctness of the 2.4 scheduler.  Like
all non-trivial software components it has bugs, and getting them
fixed is difficult, if not impossible.

> With the current scheme (OK, I am not quite up to date)
> you could write to the FIFOs of all ready processes before starting to
> wait on the baton. [giving the sub processes different priority levels
> will order them in case you have less processors than CPUs]

The current JACK implementation is completely single-threaded
regardless of how many real or virtual processors your system
possesses.

But, for some (relatively complex) graphs a multithread schedule would
be possible and desirable.  So, theoretically your point is valid.

> Maybe jack should handle the priorities for jack clients - priorities is a
> relative issue anyway... Then jackd could use this scheme when there
> is only one client to run - and the lower priority clients when there are 
> several.

What problem does this solve?
-- 
  joq