Thanks for the clarifications. I really like coop_poll's semantics (not that my opinion matters much). The classic approach to this problem is "you need low latency so we'll give you high priority whoops but not *that* high priority". Saying instead "you keep the same priority (= available CPU time) but we'll let you request where to spend it and give you feedback on what you got" seems to capture what's going on here much better. (Though it won't help much if it turns out that pulseaudio does, in fact, need more than its fair share of the CPU.)
I'm still a bit confused about how classic RT fails, though. IIUC, under SCHED_FIFO there *is* no scheduling quantum -- processes run until they yield. SCHED_RR does have timeslice-based preemption, but I can't see how any app you might care about on the desktop would ever use it. In practice, an app like Pulseaudio or Ekiga or whatever is going to yield very often, after each slice of work. Under high load it will become runnable again very quickly, but it still gives any other RT apps a chance to take over. So the apps create your effective scheduling quantum, not the kernel.