Subject: [linux-audio-dev] fullscreen video performance vs. running in window & latency issues
From: Benno Senoner (sbenno_AT_gardena.net)
Date: la loka 30 1999 - 12:55:13 EDT
Hi,
( for linux-audio-dev readers: not directly audio related but low-latency
related, and we want our realtime audio apps deliver reliable video too :-) )
I have a few questions about the actual performance you can achieve doing
graphics output using direct access techniques.
In the case of SDL in fullscreen: is the Xserver still involved in the
displaying process ?
That means: cal you achieve true hardware speed by writing directly into
the framebuffer memory (double buffering), and then flip buffers,
or are you forced to write to an intermediate graphics buffer, which is
updated by the xserver ?
I ask this because Linux is becoming low-latency capabilities
( patches available, very probably scheduled to go into kernel 2.4)
thanks to the exeptional work of Ingo Molnar who found the problematic,high
latency causing spots in the kernel.
This feature is wonderful for audio since it allows one to run
realtime audio processing with very low latency ( <3ms on a P133 !)
extremely reliably even when you stress the machine with huge
disk transfers / graphics output etc.
see the whole story, accurate tests with charts, kernel patch
and my latency measurement tool at my page:
http://www.gardena.net/benno/linux/audio
Now to my video questions:
typical video latencies are much higher than audio latencies:
realtime audio <5-10ms
realtime video <20-50ms
You can only achieve rock solid low latencies,
by using SCHED_FIFO scheduling in your process and make sure that
the pages are locked in mem by using mlock() / mlockall().
When the system is stressed with disk access, regular processes
(SCHED_OTHER) can experience bad latencies because the disk driver
/ bdflush can steal CPU time to these processes. (especially in the EIDE disk
case).
And one of these processes could be your X server.
The idea or running your X server SCHED_FIFO / SCHED_RR and mlock()ed in mem,
is simply silly, because it could eat up your entire memory and/or freeze your
system (during heavy font rendering etc).
A typical example of high performance video playback + rock solid low-latency
could be DVD playback (by software-only decoder) without frame dropouts/audio
dropouts when there is something running in background.
Assume that your DVD software player uses 50% of the CPU for the decoding,
then if in fullscreen mode the SDL (or Xv / DGA) allows you to write directly
to the framebuffer, using a low-latency-enabled kernel would provide wonderful
performance:
the video would not loose any video frames/audio fragments as long your run
SCHED_FIFO+mlock()ed , even if you do heavy disk access and/or CPU work.
What in the case that I watch my DVD movie in a window ?
Is the X server now involved ? = potential frame losses due to other processes
running in background ?
Or is there a way to use an overlay mask on GFX boards which does support
this ?
It would be ideal to specify "give me direct access to the rectancle 300x200
startinng at position (150,170) and leave out the X server of the business"
If the user changes the position/size of the video window, just update
the overlay region in the gfx board in order to reflect changes.
Could please the SDL / Xv / DGA experts explain the actual / planned
capabilities in this field.
Of course these features would put Linux much ahead in the realtime video field,
and on the same level playing field as BeOs. ( Linux becoming *the* mediaOS
soon :-) )
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:28:00 EST