Roger Larsson <[EMAIL PROTECTED]> 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
