kAudioUnitProperty_SetRenderCallback disconnecting
kAudioUnitProperty_SetRenderCallback disconnecting
- Subject: kAudioUnitProperty_SetRenderCallback disconnecting
- From: Geoff Hufford <email@hidden>
- Date: Thu, 02 Mar 2006 09:55:41 -0600
I am subclassing the Public utility class CAAudioFileReader as the source
for a graph that plays several files simultaneously. I am building with the
CAAF_USE_EXTAUDIOFILE flag, so realize that it makes the class essentially a
wrapper around the ExtendedAudioFile. The graph is organized with an
OutputUnit -> StereoMixer -> StereoMixer(s)-> CAAudioFileReader(s) input
proc.
I start the graph and when I need a portion of a file to play I "attach"
CAAudioFileReader instances as follows:
AURenderCallbackStruct input;
input.inputProc = InputProc_static;
input.inputProcRefCon = this;
OSStatus result = AudioUnitSetProperty(au,
kAudioUnitProperty_SetRenderCallback, kAudioUnitScope_Input, bus, &input,
sizeof(input));
My input proc is then called and I grab the audio and put it in the buffer.
All works fine up to this point. When the CAAudioFileReader is done with the
segment i want it to play in the input proc I disconnect it:
AURenderCallbackStruct input;
input.inputProc = NULL;
input.inputProcRefCon = 0;
OSStatus result = AudioUnitSetProperty(au,
kAudioUnitProperty_SetRenderCallback, kAudioUnitScope_Input, bus, &input,
sizeof(input));
This generally works the way I intend. The proc stops calling back and I can
later dispose of the object when I ascertain none of it's internal buffers
are busy. The problem is I get an intermittent crash which appears to only
occur when I disconnect the last CAAudioFileReader from a mixer (there may
be other readers still connected and active on other mixers). The
"EXC_BAD_ACCESS" will occur in another thread:
#0 0x99d54d04 in AUMultibandCompressorEntry
#1 0x99d54cd8 in AUMultibandCompressorEntry
#2 0x99d2063c in DLSMusicDeviceEntry
#3 0x99d16cb0 in DLSMusicDeviceEntry
#4 0x99dc8d10 in dyld_stub__keymgr_get_and_lock_processwide_ptr
#5 0x99dca90c in dyld_stub__keymgr_get_and_lock_processwide_ptr
#6 0x99cffd10 in DefaultOutputAUEntry
#7 0x99d06d6c in AUHighShelfFilterEntry
#8 0x99d003e0 in DefaultOutputAUEntry
#9 0x99dcb078 in dyld_stub__keymgr_get_and_lock_processwide_ptr
#10 0x99dcada8 in dyld_stub__keymgr_get_and_lock_processwide_ptr
#11 0x940f8e78 in AudioConverterChain::CallInputProc
#12 0x940f8ac8 in AudioConverterChain::FillBufferFromInputProc
#13 0x940f8290 in BufferedAudioConverter::GetInputBytes
#14 0x940f80e8 in CBRConverter::RenderOutput
#15 0x940f7e5c in BufferedAudioConverter::FillBuffer
#16 0x940f7fd8 in AudioConverterChain::RenderOutput
#17 0x940f7e5c in BufferedAudioConverter::FillBuffer
#18 0x940f7ce8 in AudioConverterFillComplexBuffer
#19 0x99cfffa4 in DefaultOutputAUEntry
#20 0x99dca90c in dyld_stub__keymgr_get_and_lock_processwide_ptr
#21 0x99cffd10 in DefaultOutputAUEntry
#22 0x99cff3ac in DefaultOutputAUEntry
#23 0x91414ac8 in IOA_Device::CallIOProcs
#24 0x914147dc in HP_IOThread::PerformIO
#25 0x914127ec in HP_IOThread::WorkLoop
#26 0x91412354 in HP_IOThread::ThreadEntry
#27 0x914031d4 in CAPThread::Entry
#28 0x9002b1e0 in _pthread_body
This is nearly the same call stack that I get when the input proc is
connected. The difference occurs at #1 where it would typically be
DefaultOutputAUEntry and then work its way into the input proc. It seems
that callback is still happening, but going somewhere it shouldnt.
Any ideas?
Geoff Hufford
email@hidden
_______________________________________________
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