Mike Hearn wrote:
I'm not convinced this is true. At least some (maybe most or all) of
the games showing this problem work just fine if true OSS (ie. not
ALSA-emulated OSS) is used as the sound driver. WoW and StarCraft
spring to mind immediately. Plus apparently they work in Cedega
without needing to be root, though I have no first-hand experience of
this.
Maybe for you, but this problem seems to be related to all kinds of
things ... system speed, kernel scheduler, driver combinations, what
Wine is doing at the time etc. All I know is that this works great for
me, and no, rebuilding my kernel and going back to OSS is not really an
option :)
Cedega, IIRC, either has some awful hacks or has the wineserver acquire
the privs, I don't remember which .... it'd be nice to find out.
IMHO the best way would be for wineserver to be suid root and then drop
privs. It works everywhere and is simple.
I really ought to remember to use reply-all for wine-devel. I've quoted
my first post since I meant to send it to the list.
Anyway, surely the `best' way would be for the kernel to support
user-level `real-time' priorities like the ck kernels. Anybody know why
they don't like the idea of that kind of thing?
More on topic, does this simply change Wine's priority or does it act on
a per-thread level? Most of the issues I've seen have been caused by the
audio thread being starved by the others, and is often semi-solved by
running Wine at nice 19, which seems counter-intuitive but appears to
get around some sheduling problems (priority inversions spring to mind).
This has the side effect of course that you have to make sure no other
process is going to steal the cpu time from under you. Am I talking
about the same issue as everyone else or have I got the wrong end of the
stick?
- Re: Implement THREAD_PRIORITY_TIME_CRITICAL Aneurin Price
-
