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