LKML Archive on
help / color / mirror / Atom feed
From: "Sindre Aamås" <>
Subject: Correct way for an application to sleep?
Date: Sat, 24 Feb 2007 21:54:03 +0100	[thread overview]
Message-ID: <> (raw)

I realise that this is not a question strictly related to development  
of linux, but there have been changes related to sleep granularity  
lately, and I'm assuming these changes are made with an idea of how  
sleep functions are expected to be used from user space. Since some of  
these changes have made my situation worse (although the recent  
development wrt high-res timers and dynamic tick looks promising), I'd  
like to know if situations like mine are accounted for in the plans  
behind such changes, or if I'm just relying on the wrong things here,  
and how the kernel wants a user space app to behave wrt this.

I'm developing a game console emulator. This needs to be synced to the  
host's time at regular intervals, eg. 70224 emulated cycles pr  
~16.7427 ms. This should preferably happen once every frame, so that  
the next frame lasts as long as the previous, giving non-choppy  
display. At the same time I need to resample the emulated sound to the  
host's sample rate, and stream it to the sound card. This means that  
if I fail to consistently keep within these limits I will get choppy  
display, and fluctuating pitch (or buffer underruns depending on how I  
resample). One way to keep within these limits is to busy-wait, but  
that seems like a kind of obnoxious way for an application to behave,  
not to mention that it will drain an eventual battery (and probably  
cause global warming, kill kittens etc.). So, I would like to give  
away as much cpu time as possible keeping within these limits.

If I have access to waitForVblank()-like functions I could supposedly  
resample the emulated video to the host's frame rate and use this.  
Unfortunately I often don't have that possibility, besides resampling  
frame rate in real time can be very resource intensive (and give  
motion blurry visuals).

Afaik, if I were to sync by means of sound hardware needing more  
samples, I wouldn't be able keep a consistent frame rate. Unless I can  
set a weird buffer size, use a static resampling ratio, and  
approximate the emulated system's speed slightly. If there are more  
sophisticated ways to sync through sound hardware, that may be a  
complete solution (for my specific case).

Without root-privilegies, that leaves general purpose sleep functions  
like nanosleep afaik. The problem is that the granularity of these  
seems very unpredictable, and if I am to use a lowest common  
denominator I'd only be able to sleep like 10 ms pr 16.7 ms on fast  
systems, and not at all on not so fast systems. So, I'd like to know  
what the "correct" way to handle this kind of situation is, if any,  
from a kernel perspective. Is the only sensible thing to do to give a  
user settable preference, deciding on a compromise default (or one  
that says "screw you old kernels")?

Please keep me CC'd if you reply to this thread.


             reply	other threads:[~2007-02-24 21:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-24 20:54 Sindre Aamås [this message]
2007-03-02  1:43 ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: Correct way for an application to sleep?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).