Subject: RE: [linux-audio-dev] Big Qthread vs. pthread and usleep problem
From: Ivica Bukvic (ico_AT_fuse.net)
Date: Fri Nov 30 2001 - 04:34:28 EET
> 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.
This archive was generated by hypermail 2b28 : Fri Nov 30 2001 - 04:27:18 EET