>Has anyone done any low-latency audio testing with the new native pthread >implementation (comes with rh9.0 at least)...? > >I was just reading through [1] and noticed the following (in section 8): > >""Realtime support is mostly missing from the library implementation. The >system calls to select scheduling parameters are available but they have >no effects. The reason for this is that large parts of the kernel do not >follow the rules for realtime scheduling. Waking one of the threads >waiting for a futex is not done by looking at the priorities of the >waiters."" > >If I've understood right, SCHED_FIFO semantics do not have any meaning >between threads of one process if NPTL is used! Hopefully this is right, >as it would cause quite a lot of problems (GUIs and disk i/o threads can >freely block audio processing even though using SCHED_FIFO). :( > >[1] http://people.redhat.com/drepper/nptl-design.pdf
i just told penguin computing that i could not buy a machine from them if it came with RH9. ulrich (drepper) is wrong to say "large parts of the kernel", he is right to say "significant parts of the kernel". i hope that linus will not release 2.6 until this is fixed. we need to find the right place to speak loudly about this issue. otoh, look on the bright side. i suspect that ulrich is saying that SCHED_FIFO is not *necessarily* obeyed, in that if more than 1 thread is waiting on a futex, the futex code will not ensure that its the SCHED_FIFO one (or the highest priority one in general) that is woken. however, if you're using futexes for 1:1 communication (typical), then this shouldn't matter. in the case of JACK, for example, its always 1:1, and i think this would be true for audio<->disk i/o thread communication too. what would be *really* bad is if they actually changed the code so that attempts to set SCHED_FIFO are not honored because they believe they are useless. i don't know which of these is true. --p