Implement THREAD_PRIORITY_TIME_CRITICAL

[Robert Reif]

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...
>
>Andreas
>
>
>
>  
>
One problem that I am seeing is that there is no practical way to
guarantee synchronization between the sound card hardware and the
sound card thread.  OSS doesn't support poll/select reliably in
all drivers and the esd driver just writes to a socket.  We try to
synchronize to the hardware by using a one-shot timer set to the
expected processing time calculated from the sound card data
format.  The problem I see in the esd driver is that we set a
timeout to poll of for example 12 ms but what we really get is
is a 20 ms sleep.  We compensate for this by sending as much
data as we can.  Using virtualized hardware like alsa dmix just
removes us even further from the hardware we would like to
synchronize to by blocking.