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: William Stewart <email@hidden>
- Date: Mon, 27 Mar 2006 11:48:35 -0800
On 25/03/2006, at 3:26 PM, Christopher Ashworth wrote:
Is the callback procedure for AudioConverterFillComplexBuffer
guaranteed to be called in the same thread that called
AudioConverterFillComplexBuffer,
yes
or is it called from a separate worker thread?
no
There's no threading internally in the converter.
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.
right - this is the condition you have to guard against.
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...)
probably not needed.
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?
not alot :-( What do the crash logs look like?
Bill
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.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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