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