On Thu, 13 Oct 2005 15:16:36 +0200, Nicolas George said: > What I want is a displayed clock that *changes* precisely at the time the > internal clock value changes. With careful programming, I can get that with > "precisely" = the intrinsic system latency, which is pretty good (less than > a CRT screen refresh, on idle modern systems). Something to keep in mind - the system's *internal* clock is usually going tick-tick-tick at some high speed (100HZ to 1000HZ for recent Linux kernels, for example). It also usually has a very good notion of "500 milliseconds from now" and similar timeouts. However, any conversion to "seconds" is more or less entirely for the convenience of the liveware using the system. Given that you already *know* there's up to 0.5 seconds of difference, it seems that what you want *isn't* "precisely the same time the internal clock value changes". What you want is a guarantee that *this* change will be almost exactly 1 second since the last change - in other words, if the last time it changed was actually at :45.34, you want the next one to be between :46.32 and :46.36 or so... (I'm sure that Paul can talk in detail about getting *real* timestamps, such as per-frame SMPTE timestamps, which is a *whole* different kettle of fish ;)
Attachment:
pgpIvIYFK9v3D.pgp
Description: PGP signature