Implement THREAD_PRIORITY_TIME_CRITICAL

[Mike Hearn]

>> You're missing the point.

It can screw things up on multi-user servers where uptime is important 
and you don't want just anybody to hang the box. I don't think it's a 
big deal on a desktop where the absolute worst case is you have to hit 
the reset button.

>> What we need is a mechanism that
>> is safe enough to be enabled by default on all systems, without
>> requiring suid root or similar hacks.

Yep, that'd be great, but I don't know of one. If anybody has any more 
suggestions please speak up!

SCHED_ISO has been proposed, but it's not in the mainline kernel and in 
one thread somebody writing a low-latency audio app found it didn't 
improve things enough. Con Kolivas said - sure, if your app needs 
SCHED_FIFO then that's what you have to use. So there's no guarantee 
this approach is viable.

Changing buffer sizes may be another alternative but nobody has written 
a patch for that, nor shown that it actually works and doesn't break 
apps in some other way.

So for these reasons, my opinion stays - I would rather we use and 
refine this known to work solution than wait for a perfect one to 
arrive, as in the meantime users will be saying "Oh Wine sucks for 
games, use Windows" or "Wine sucks for games, use Cedega". Which doesn't 
solve anything. If/when somebody comes up with a kernel patch or clever 
patch that removes the need for root, great! Let's use it.

> Alex, I got one idea: Wine-level timeslicing. While this would be doing 
> what the standard VM system in all OSes does already, it would allow for 
> us to priortize processes within Wine, controlled by Wine.

Segin, I don't think that'd work, this is a variation on the "let's just 
drop the priority of every other thread" idea. The problem is that this 
doesn't have the same effect, the kernel still doesn't schedule the Wine 
threads often enough to get corruption-free audio.

There are two ways to attack this issue - either getting the kernel to 
schedule a TIME_CRITICAL thread often enough that it works without risk 
of freeze, or making Wines audio less susceptible to scheduling glitches.

The first one requires us to either use elevated privs, or find and 
implement some scheduling algorithm that gives us what we want. Our 
track record at getting big changes into other projects is poor and it 
will be years before it's widespread even if done tomorrow. The second 
one will break as much as it fixes: pro audio apps will never work 
properly when there is a high amount of latency, and it may interfere 
with games too (eg sound effects not matching what you see on screen).

It's a rock and a hard place, and we're stuck between them :(