mike at plan99.net
Sun Apr 2 17:40:35 CDT 2006
>> 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 :(
More information about the wine-devel