Audio stuttering issue
Chris
chris.kcat at gmail.com
Thu Jul 27 17:05:12 CDT 2006
On Thursday 27 July 2006 06:10, Mike Hearn wrote:
> On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote:
> > Or if you still don't want something like that merged in, I'd like to
> > alert the author of that patch that it doesn't require root privs to
> > work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
>
> Thanks for the heads up. I'll let Alexandre comment on the other stuff but
> I wanted the patch to work out of the box for all users, with no
> configuration necessary.
It does. You don't really have to change anything. Only thing that'll happen
is the setup_security function won't do anything, but the set_thread_priority
funciton would still work. It's just a difference of setting the suid root
bit and re-chown'ing /tmp/.wine-* all the time, or setting a non-zero
RLIMIT_RTPRIO value for the user. I just think it'd be nice to let users of
that patch know they don't need to run Wine with root privs if they don't
want.
> I don't see any way to resolve this issue satisfactorily. Windows apps
> require hard real time support, the kernel won't give it to us without
> privileged access, Alexandre doesn't want to let Windows apps do that.
I personally don't see what's wrong with letting the user decide. Without
setting the suid root bit, Wine won't get any more privileges than any other
Linux app run by the same user would get. Wine would just take advantage of
the capabilities of a new-ish kernel feature (one that was explicitly added
in, mind you; it's not a side effect or unforseen consequence) for the exact
reason it was made.. to allow user space apps to get real-time priority, as
defined by the user's system settings. It wouldn't be automatic, so Wine
couldn't deadlock the system without the user explicitly setting the resource
limit. It's exactly what Wine would need, so why not use it?
More information about the wine-devel
mailing list