Locking the CoreAudio thread
Locking the CoreAudio thread
- Subject: Locking the CoreAudio thread
- From: "Timothy J. Wood" <email@hidden>
- Date: Fri, 18 Jan 2002 12:29:12 -0800
We've run into a pretty ugly bug with our Netscape plugin support in
OmniWeb that involves CoreAudio.
We have the main thread feeding data to a plugin (for a Flash movie in
this case). Also, the plugin is playing sound and so there is a
CoreAudio thread running in the background.
The problem comes when CoreAudio tries to get some more data to play
and calls back to SoundManager. SoundManager decides that one of the
sound commands has completed and calls back into the plugin code. The
plugin is apparently not thread safe, though, since this crashes if the
main thread happens to be calling into the plugin (to feed it some more
data).
What we need is some way to take the CoreAudio lock (or SoundManager
lock) while we are talking to the plugin so that the main thread and
sound thread cannot both be accessing the plugin at the same time.
There may be other ways to fix this problem, but essentially we need
to either have a thread safe plugin (not likely) or we need to prevent
two threads from calling into the plugin at the same time.
Any suggestions on how to temporarily block CoreAudio from issuing
callbacks would be much appreciated. Presumably IE avoids this problem
somehow...
The only idea I've come up with so far is to NOT submit data to the
plugin (or make any other calls to the plugin) in the main thread, but
instead to register callBackCmd commands with SoundManager and do our
work there. This would be truly terrible and would have problems of its
own (like synchronizing drawing with the main thread). I don't think
this is a very feasible solution.
I suppose I could issue a callBackCmd that would signal when it
started (via a pthread_cond_t), and block on a mutex until the main
thread said it was done. This also seems terrible (and would involve a
bunch of overhead).
Is there a better way?
-tim