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