Re: Conclusion: Can anyone comment on Crashes in AUParameterSet?
Re: Conclusion: Can anyone comment on Crashes in AUParameterSet?
- Subject: Re: Conclusion: Can anyone comment on Crashes in AUParameterSet?
- From: Doug Wyatt <email@hidden>
- Date: Fri, 30 May 2003 15:44:30 -0700
I've traced the usage of the AUParameter pointer through
AUParameterSet. AUParameterSet does *not* retain any references to the
pointer.
I'll reiterate what I wrote about this on 5/27:
[a] it's important to know what the other threads are doing. In gdb,
use "t a a bt" to get a backtrace for all threads. There could be a
critical region that's not protected with a lock.
[b] if that's not the problem, then step instruction-by-instruction
through AUParameterSet. It's not very long. Your AudioUnitParameter is
passed in in R5, copied into R30 (hopefully my compiler isn't too
different than the one Jaguar was built with). If this was a bad
pointer, we'd crash before pulling out the parameters to
AudioUnitSetParameter. It's not crashing there, so the first thing I'd
check is to see if AudioUnitSetParameter is trashing R30 before passing
it to NotifyListeners, in which we're crashing.
[c] if that's not it, then I have to suspect a memory corruption bug.
Doug
On Thursday, May 29, 2003, at 07:31 US/Pacific, Shai Shasag wrote:
Hi to all,
It is my conclusion that AUParameterSet IS asynchronous. If you
remember my code was:
const AudioUnitParameter inParameter = {GetComponentInstance(),
lParamID kAudioUnitScope_Global, 0};
OSStatus cErr = ::AUParameterSet(nil, nil, &inParameter, newValue, 0);
&inParameter is a pointer to the stack, and therefor does not live
after the function ends. The crash happened inside memcpy (call from
somewhere in AUParameterSet).
What I did was to create an array of AudioUnitParameter's and placed
it on the heap.
Now the call is:
OSStatus cErr = ::AUParameterSet(nil, nil, inParameterArray +
lParamID, newValue, 0);
Now I do not crash any more.
So I can only conclude that the third parameter is being use after
AUParameterSet returns.
As for calling from the audio thread. If I understand correctly by
'audio thread' you mean the component derived from AUBase. If so this
code is being called from the audio thread and (now) without > problems.
thanks to all who helped,
Shai
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.