[SDL] very precise control of display timing

David Olofson david.olofson at reologica.se
Thu Aug 23 07:29:01 PDT 2001

On Wednesday 22 August 2001 09:39, Pallier Christophe wrote:
> Hello,
> I would like to describe an apparently simple project and ask people
> on this list if they believe there is a way to achieve it with SDL
> (under linux). In a nutshell, I wonder if it is possible to get control
> of display duration down to the screen refresh rate.

Generally, no, not in any reliable way.


> Long ago, I wrote a DOS program in Borland Pascal that does just that:
>   do
>    wait for the specified number of vertical retrace synchro signal
>    swap hidden and visual page
>    prepare next picture in the hidden page
>   loop
> It worked well, but the only (big) proble is that the 10 years old
> Borland BGI drivers only knows about plain VGA video mode...
> The problem is much more complex under linux, it seems to me, because
> of the multitasking OS:

Right, there's no way to hit all of the very short-lived retraces by 
polling the VGA registers. You need some real time solution to it that 

However, if you time the refresh rate with a very accurate timer (such as 
the pentium TSC), you can look at the timer to find out how many frames 
have elapsed. Resync the timer to actual retraces whenever possible.

Either way, to actually *do* something at the right time (as opposed to 
just finding out when something happened), you still need a real time 

> How can I be sure not to miss a vertical retrace signal? (i.e. how can
> I be sure that my process is going to be running at this critical
> moments?)

Use Linux/lowlatency and a SCHED_FIFO thread for the retrace polling. You 
can use the RTC to wake the polling thread up right before the retrace is 
expected. The TSC (RDTSC x86 instruction) is useful if you can get away 
with just knowing *when* the retrace occured/will occur.


Even better, but a little bit more complicated; do the same thing with 
RTlinux or RTAI. You can safely wake up just a few 10's of µs before the 
expected retrace time, poll, write some data (the current frame count, 
for example) to an RTL FIFO, and then put your thread to sleep again. 
Timing is µs accurate, and worst case latencies are in the 5-20 µs range 
depending on hardware.



Note that the solutions above only helps for about half of the problem; 
keeping track of the retraces. You still need to use Linux/lowlatency and 
carefully selected drivers to solve the rendering part.

You can't run SDL as an RTL thread, and you can't rely on all SDL targets 
to benefit from SCHED_FIFO, or even work with it! For example, it's 
possible to run X and X applications as SCHED_FIFO, but some applications 
will freeze the entire system. X and normal X applications aren't 
designed to run as real time threads without timesharing preemption.

//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'

More information about the SDL mailing list