Re: crashing in calls to AudioConverter on 10.3.9
Re: crashing in calls to AudioConverter on 10.3.9
- Subject: Re: crashing in calls to AudioConverter on 10.3.9
- From: Christopher Ashworth <email@hidden>
- Date: Sat, 25 Mar 2006 18:26:00 -0500
Is the callback procedure for AudioConverterFillComplexBuffer
guaranteed to be called in the same thread that called
AudioConverterFillComplexBuffer, or is it called from a separate
worker thread? AudioConverter.h doesn't say. (Or mention anything
about threads at all.)
There are three threads that I am aware of that I must coordinate in
my sound file object: 1) the main thread (i.e. the application's "GUI
thread" from which calls to do things like start and stop the sound
file are received. 2) the HAL render thread from which my render
callback is called. 3) My own worker thread which periodically polls
my sound buffer and ensures it is replenished while the sound is
playing. I want to make sure these are, in fact, the only threads I
must coordinate.
I am sure that for any one of my sound file objects all access to the
AudioConverterRef is controlled via a lock. Thus, for example, the
AudioConverterReset function is not being called in the middle of the
AudioConverterFillComplexBuffer function. In fact, the entire
function that fills the audio buffer is wrapped in a lock, and no
resources used in that function can be modified without acquiring
that lock. (I've used the same lock in the audio converter callback--
so even if the callback is being invoked from another thread it
*ought* to be safe...)
Nonetheless, I see crashes only in the
AudioConverterFillComplexBuffer function. And I only see the crashes
on 10.3.9, which may well be a red herring, but is rather odd, since
in the four days I've been trying to track this down, I've produced
dozens of crashes on 10.3.9, and zero on 10.4.5. The herring
therefore seems less red.
Thoughts?
Chris
On Mar 22, 2006, at 7:53 PM, Christopher Ashworth wrote:
On Mar 22, 2006, at 7:39 PM, William Stewart wrote:
The AudioConverter is intentionally not thread safe - that is, you
can't be in one thread, calling the Reset call, while in another
thread calling the convert call. If you are sharing an instance of
the converter in multiple threads, you'll have to ensure single
access through a mutex or some similar technique.
This is the only idea I've had so far--that I'm not ensuring thread
safety. I had thought everything was safely wrapped in a lock,
but I will re-audit to look for unprotected AudioConverter calls.
The 10.3.9 vs 10.4 thing may just be a red herring that was
throwing me off track. I prolly shouldn't have jumped to the list
before triple-checking the threading issue.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden