I'm trying to write a timing loop in my empeg app that maintains more or less a constant frame rate. You can imagine that such a loop would be very handy for games etc. Here's my current attempt:

struct timeval frameTime, startTime, currentTime, deltaTime, padTime;

struct timespec padTimeSpec;



frameTime.tv_sec = 0;

frameTime.tv_usec = 1000000 / FPS; /* desired frames per second */



while (looping) {

  gettimeofday(&startTime, NULL);

  

  /* update the application here */

  

  /* calculate sleep time to required maintain desired FPS */

  gettimeofday(&currentTime, NULL);

  timersub(&currentTime, &startTime, &deltaTime);

  timersub(&frameTime, &deltaTime, &padTime);

  if (padTime.tv_usec > 0) {

    /* have a sleep */

    TIMEVAL_TO_TIMESPEC(&padTime, &padTimeSpec);

    nanosleep(&padTimeSpec, NULL);

  }

}

At present, when running my app with the player software going under hijack, and setting a target frame rate of 30 fps,
it takes about 50 seconds to do 1000 updates, whereas it *should* take around 33 seconds.

Am I approaching this the right way or am I completely off track? I can't say I'm very experienced at unix programming so if somebody has any suggestions I'd be very grateful.

Cheers,

Richard
--

Well one thing to consider is that nanosleep calls are at the mercy of the scheduling policy, and the player uses realtime scheduling. Unless you switch your app to the same scheduling policy (SCHED_RR I believe) you aren't guaranteed to get any CPU at all.

Here's how I do it in emptriv, which is a little slow with the default scheduler:

#include <sched.h> 



#define PRIORITY 30



struct sched_param  sched_param;

int iPid, rc;



iPid = getpid();

rc  = sched_getparam(iPid, &sched_param);

sched_param.sched_priority = PRIORITY;

rc = sched_setscheduler(iPid, SCHED_RR, &sched_param);	

rc = sched_setparam(iPid, &sched_param);

.

I suspect that if you switch to SCHED_RR, you'll get more consistent timing, though you might have to tweak the priority. Anything beyond 30 and you might start stealing too much from the player. At least those were my results.

Not sure this is the problem, but it's one possibility.

Yeah, I figured it could be that the player is too resource hungry. I just wanted to be sure that it wasn't a bug in my code or that there wasn't a better way to approach the problem. Will try your suggestion of upping the priority to see what difference it makes.

Thanks,

Richard
--