On Wednesday 05 April 2006 00:34, Andreas Mohr wrote: > Hi, > > On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote: > > On Wednesday 05 April 2006 00:06, Mike Hearn wrote: > > > I think for now I shall just maintain this patch out of tree so savvy > > > users can apply it and get glitch-free audio. I have never been > > > convinced by this sacred devotion to avoiding SCHED_FIFO: the > > > restrictions behind it make total sense on a server where you have > > > multiple users who may be untrusted. I doubt most end-users care on a > > > desktop with a readily accessible reset button. A game goes batty and > > > hangs the machine - oh well, hit reset and don't play it again. Problem > > > solved. > > > > Don't give up now as you will convince everyone else there is no solution > > and only your patch will make games work. Your attitude is defeatist > > because you're convinced that real time scheduling is your saviour. I'm > > trying to help you here, so can you do me one favour and try 2.6.17-rc1 > > without any special patches and tell me how it currently performs? > > I have the same feeling here. > We have a *small* winealsa (or whatever audio backend you choose) thread > that one would think does *minimal* audio processing, so there really > shouldn't be *any* reason for this to not work, since as said before a > thread with minimal CPU runtime and specific wakeup requirements should get > scheduled just perfectly with a current scheduler mechanism that honours > minimal CPU use of a thread with high-priority wakeup performance. > > Since it doesn't seem to work, either Wine's audio thread gets out of hand > and consumes way too much CPU (maybe it gets confused by some weird audio > polling behaviour of a Win32 app) or the current scheduler(s) don't honour > such a thread optimally. Or... the Wine neighbour threads call into weird > system calls that don't behave optimally (i.e. they prevent proper > scheduling by not allowing preemption for larger periods of time). > > And this all should work perfectly well with NON-soft-realtime scheduling, > as clearly said before. > Well, in theory, at least...
Andi just out of interest, how does normal scheduling on current ck (2.6.16-ck3) perform with this? Cheers, Con
