> You can't "just sleep" for less than 20ms. The system timer has that > resolution (at least, by default on x86; its different on other > architectures and it can be changed at kernel compile time), and it is > what is used to wakeup processes that call sleep/usleep/nanosleep. see > below for more.
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 fact that usleep, as you have pointed out, does minimum 20ms counting, which is twice the resolution I am looking for), and that is ok for now since the app is designed for rt performance (interaction between performer and computer, and as such anything less than tenth of a second is pretty much an overkill, but is there nonetheless). I originally made an infinite loop checking through ftime the passage of milliseconds, but since it was an infinite loop checking as fast as possible (in order to avoid inaccuracies, and at the same time I was unable to use sub-20ms usleep function to ease the load on the cpu), it left a huge footprint on my system resource usage (~97% on a 1Ghz P III laptop). Now, that I am using usleep, with this 20ms limitation, I have between 0 and 1%. This is crucial for my app, since it is only a front-end for other sound-oriented processes (i.e. rtcmix, csound etc.), so my app needs to have smallest footprint possible, and right now seems to be doing ok in that department, thanks to usleep. 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. As far as my code is concerned, well it's so messy that I am honestly embarrassed to show it until I make serious improvements, esp. due to fact that app still does pretty much nothing :-). In another words, I am still exploring the best ways of doing things. Hope you'll understand. Thank you for your ongoing assistance and support! Sincerely, Ivica Bukvic 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.
