Subject: [linux-audio-dev] realtime mouse/video .. Was: Re: SCHED_FIFO machine stalls
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe joulu 10 1999 - 18:11:09 EST
On Fri, 10 Dec 1999, Alexander König wrote:
> maarten de boer wrote:
> > I'd say that especially for terminatorX you *do* want the
> > GUI to have decent speed, at least the mouse-event handling.
> > Maybe you need a seperate thread for the mouse-events, but
> > maybe this complicates things too much...
>
> Well on my machine plain gtk works pretty good - the widgets that need
> speedy updateing are those I've written myself (the wavdisplay and the
> new "level-meter") and as they're not standard they're not modified by
> themes... Oh and the mouse input stuff happens in the audio-thread with
> direct XFree-DGA mouse grabbing - no unnecessary latencies here ;)
The type of widget toolkit doesn't matter (slow or fast) as long as you run the
GUI thread with lower priority than the audio engine.
The problem could be the interaction with the X server,
even if you read only mouse events via DGA, but you must go through the
X server.
I'm beginning to really hate the Xwindows concept from a realtime POV,
I discussed this a bit with Alan Cox and Daryl Strauss (of Precision Insight),
and they effectively admit that X is not designed from the ground up for
real-time use, or at least speaking in terms of an X server implementation.
I think a suitable solution could be to run the core X server part which
has to cope with realtime tasks (dispatching loop,blitting)
as SCHED_FIFO / SCHED_RR (with lowest priority) thread,
and run a 2nd X server thread which does the non-realtime things like pixmap
allocation , memory handling etc. since these things are all non-deterministic.
Associate a priority to each X connection id
(similar to SCHED_FIFO and SCHED_RR) in order to let the X server execute
X requests from the higher priority Xclient, before all other clients.
( yes this could stall other X11 apps completely if the "realtime-X" client
uses the full Xserver bandwidth, but you asked for realtime and you got it :-)
)
I tested terminator-X while doing heavy disk I/O , CPU stuff etc in background,
on a low-latency kernel the audio doesn't drop out, but the mouse
responsiveness get very bad since the poor X server doesn't get rescheduled
in time in order to provide a smooth mouse event-stream to the app.
The resulting scratch sounds very crappy since , events come in bursts.
On the real-time audio side, we are now ok thank to the lowlatency stuff,
on the realtime video (which comprises keyboard+mouse managed by X)
we have still this problem, and I think it is not as trivial to solve as it
was for audio.
I hope that SGI will bring some expertise in this field since they are
one of the major players in the realtime rendering/video fields.
(Daryll told me that they have still problems , even with XF4.0 DRI ,
when there are disturbing task in the background)
comments ?
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST