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: Mon, 27 Mar 2006 22:34:01 -0500
On Mar 27, 2006, at 10:12 PM, William Stewart wrote:
OK - so this implies to me that you still have a thread somewhere
else calling reset on this converter.
<snip>
What are the other threads doing in the crash log? If this is a
threading problem, then just looking at the thread that is crashed
is not going to help you. What is the topology of the converters -
do a CAShow on this converter (just so we can see what conversion
operation it is doing).
The fact that this isn't crashing on 10.4 would have led me to
believe that this was some other internal conv problem, but the
fact that this goes away when you lock around the call is very
strongly suggesting that your code is reseting some state...
The other thing is this.
The buffer that your input proc provides to the converter MUST
REMAIN valid until the next call to your input proc. The audio
converter will attempt to not copy the buffer of memory you provide
if at all possible. So, if you are de-allocating the buffers you
provide, or even reusing them, would be problematic (and could be
indicative of the crash above) - but then if that were the case,
that suggests that the addition of the synch call is actually
keeping you from deallocating an input buffer then (or some such).
I will do the CAShow on the converter as you suggest and post the
result, and I will also post what the other threads are doing.
The important thing to note here is that the synchronization:
@synchronized(converter_semaphore)
is not done anywhere else. That is the *only* place that is
synchronized on that semaphore. So the *only* thing that is being
locked out is other calls (from other sound objects) to the
AudioConverterFillComplexBuffer function.
(As a side note, the conversion buffer is locked via an NSLock so
that it cannot be released or otherwise touched until the fillBuffer
function--the one that is calling AudioConverterFillComplexBuffer--is
complete.)
I'll go grab some more crash log data now.
But at the risk of being bone-headed about it, I just want to stress
that the @synchronized block displayed in my last email is literally
the only difference between the two programs. Because this semaphore
is not used anywhere else, the only code that this is protecting is
what is inside the AudioConverterFillComplexBuffer function. Thus,
if my input callback looks safe, then (as I understand it) the
problem must lie somewhere in AudioConverterFillComplexBuffer.
Or am I making a mistake in my logic?
C
_______________________________________________
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