Re: [linux-audio-dev] Big Qthread vs. pthread and usleep problem

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Big Qthread vs. pthread and usleep problem
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Nov 30 2001 - 05:34:19 EET


>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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Nov 30 2001 - 05:35:28 EET