> 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.
Yes, I am aware of this, but my program will not handle audio directly. It will be only the front end which will execute system calls to the audio processes as needed, thus the timer I need will be completely independent from any kind of audio data flow, or audio-related process. This is why I am looking for a separate timing thread, so that my front-end gui does not "freeze" due to infinite timer loop (if it were executed within the same thread which manages gui), if this makes any sense :-). I am not sure whether this is the most sane/efficient approach, but this being my first audio-related gui app, I am using it to learn as I go :-) Thanks to all of you who responded to this question, I did finally solve the problem with the QObject::startTimer() call which has 10ms resolution (exactly what I need) and results in 0.00 cpu usage when running (according to the Process Manager). Big thanks to all of you who generously offered your help! Sincerely, Ivica Bukvic
