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 :(