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.
