>Well, the way I've been doing stuff so far is that there's a thread that >is created before even the main widget is shown, and it depends on a >value from the main widget which designates the playback state (i.e. >stopped, playing, paused, etc.). When the playback state becomes >"playing," the "if" condition within the thread is fulfilled, and thus >begins the time counting, and it seems to work fine (considering the
why would you count the passage of time from within a dedicated thread? whatever delivers audio data to your audio interface is also counting time, though you may not realize it. lots of other programs do this kind of thing; they do not have a dedicated thread counting the passage of time in this way. they count audio time by the passing of audio frames; if they need wall clock time, they use gettimeofday(2) or ctime(3). >Still, the question remains, how to get better than 20ms resolution >without hogging the cpu? Usleep seems out of question if I want to go >beyond the 20ms threshold. the traditional way to do it is to sleep on some event that happens with greater frequency. you could have one such thing in your program: the audio interface's interrupt, which is quite likely to be occuring more often than every 20ms. or perhaps not. if thats not available (you said you were writing a front end), then you'll have to use the RTC. see this: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/ardour/ardour/libs/ardour/rtc.cc?rev=1.1&content-type=text/plain for some sample C++ code. you have to be root (or have CAP_RESOURCE) to program it with any useful frequency. >P.S. It seems to me that the author of usleep should make sure that the >usleep man page reflects this important limitation, since there is no >mention of usleep being limited by the 20ms threshold, although it is >quite possible that the limitation is not in the usleep code, but rather >in the kernel architecture, as you have pointed out. precisely. on a kernel with HZ=1000 (e.g. on the alpha), usleep resolution is 1ms. --p
