31 Mar
2004
31 Mar
'04
2:23 p.m.
On 31 Mar 2004 10:44:15 -0600, Jack O'Quin <joq(a)io.com> wrote:
Arve Knudsen <aknuds-1(a)broadpark.no> writes:
True .. That was one approach I considered originally while sketching up
solutions, I guess it slipped my mind in the meantime :| I was thinking it
could possibly be an expensive operation though as NPTL sources seem to
indicate, maybe best avoided if memory locks are involved (I'm no
optimization guru, I'm sure you can tell). Anyway, do you think it would
be good to keep a canary around to act on CPU starvation?
Thanks
Arve Knudsen
The thing is I don't have complete control
over the audio thread, a
user defined callback is involved. In working on the ALSA
implementation of the PortAudio library there has been a request for
realtime scheduling of the audio thread, similar to the older OSS
implementation. The OSS implementation starts both a watchdog and a
canary thread; the watchdog will kill the audio thread (with SIGKILL)
if it doesn't respond within 3-second intervals, or lower it's
priority if the (normal priority) canary thread is starved.
You can do something like this...
int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
/* invoke the callback */
framesProcessed = PaUtil_EndBufferProcessing( &stream->bufferProcessor,
&callbackResult );
/* restore original canceltype setting */
pthread_setcanceltype(oldtype, NULL);