Audio stuttering issue

Chris chris.kcat at gmail.com
Thu Jul 27 04:18:49 CDT 2006


I know there's been discussions on this before, and the only concensus reached 
was "use kernel 2.6.17", which apparently helps with processes that wait on 
pipes. There was this patch (which I tested and did have a very noticeable 
positive effect):

http://wiki.winehq.org/Implement_SetThreadPriority

that uses sched_setscheduler to change the scheduling policy and priority of 
the thread, but was rejected because it always ran privileged and allowed 
apps to deadlock the system if it ran a real-time thread without yielding. 
However, when looking at my man pages, I found this:


Since Linux 2.6.12, the RLIMIT_RTPRIO resource limit defines a ceiling on an 
unprivileged process's priority for the SCHED_RR and SCHED_FIFO policies. If  
an unprivileged process has a non-zero RLIMIT_RTPRIO soft limit, then it can 
change its scheduling policy and priority, subject to the restriction that 
the priority cannot be set to a value higher than the RLIMIT_RTPRIO soft 
limit. If the RLIMIT_RTPRIO soft limit is 0, then the only permitted change 
is to lower the priority. Subject to the same rules, another unprivileged 
process can also make these changes, as long as the effective user ID of the 
process making the change matches the real or effective user ID of the target 
process.  See getrlimit(2) for further information on RLIMIT_RTPRIO. 
Privileged (CAP_SYS_NICE) processes ignore this limit; as with older older 
kernels, they can make arbitrary changes to scheduling policy and priority.


Meaning, if a user has their system set so that a user (or specific user(s)) 
have a non-zero RLIMIT_RTPRIO rlimit, normal unprivileged apps can change 
their scheduling policy and increase their priority up to that value; exactly 
what that patch does, but without needing special privileges. What would you 
think about implementing that patch so that it runs unprivileged, but allows 
the user to set their system so Wine can set time-critical thread scheduling? 
In this way, it would be completely up to the user if they wanted to run an 
app that can set real-time scheduling for cleaner audio, or not and have 
potential stuttering.

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).



More information about the wine-devel mailing list