29 Nov
2003
29 Nov
'03
11:35 p.m.
On Sunday 30 November 2003 03.19, Jack O'Quin wrote:
It will better match what you think you do.
When jackd writes in the FIFO - expect client to start.
Jackd waits for baton - wait for client to finish.
But with jackd as highest priority:
Jackd writes to FIFO - nothing will happen for client.
Jackd _waits_ for baton - now client start, processes, finishes.
You could try a low priority jackd (still RT) in this way to see if
things behave better.
Next week I will read some jack and kernel code if you can try
to explain what happens.
/RogerL
--
Roger Larsson
Skellefteå
Sweden
Roger Larsson <roger.larsson(a)norran.net>
writes:
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.
Have you told kernel developers about this?
This can be rather critical in embedded systems.
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! Like all non-trivial software components it has bugs,
and getting them
fixed is difficult, if not impossible.
But the scheduler is VERY simple when you are using RT (SCHED_FIFO/RR).
It only selects the one with highest priority.
So unless your thread falls off the run queue - critical.
Does not timely get on the run queue after wake up - critical.
Gets stuck somewhere else - program bug?
But it could also be jackd the gets stuck doing something else...
(this is the reason why I am not comfortable with the printfs in
my rt_monitor - they use the console and it is bad...)
Anyway try to describe your problems in linux-kernel (cc me)
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?