[Stk] possible race condition in RtAudio

[Tristan Matthews]

Hi,

I've come across a peculiar case in RtAudio using the ALSA backend.
Once in a while, the audio callback thread will just hang, waiting for
a pthread condition variable (apiInfo->runnable) to be signaled in the
callbackEvent method. It seems that sometimes the main thread signals
this variable (at the end of startStream) before the audio thread has
a chance to wait for it, so the audio thread just ends up waiting
indefinitely. Now unfortunately this bug is very hard to reproduce, so
much so that I've only managed sometimes and usually just in the
context of running an RtAudio program with GDB (so not a very
representative case). I've attached a slightly modified version of the
threebees.cpp example program which moves the creation of the
instrument object to before the calls to openStream and startStream,
which seems to increase the frequency of this bug.

My guess is that the following happens:

1) openStream() is called, which subsequently calls probeDeviceOpen
which spawns the audio thread.
2) startStream() is called, which signals the apiInfo->runnable
condition variable. However, it's possible that the audio thread
(created by probeDeviceOpen) has not yet started waiting on this
variable, in which case, the audio thread will wait indefinitely.

This case is more likely if the call to startStream happens
quickly/immediately after the call to openStream, with no other calls
in between.

Hopefully someone else will be able to reproduce this.

Best,
Tristan
-- 
Tristan Matthews
web: http://tristanswork.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threebees.cpp
Type: text/x-c++src
Size: 4480 bytes
Desc: not available
Url : http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20110717/4fc1f215/attachment.bin