AUGraph init sequence questions
AUGraph init sequence questions
- Subject: AUGraph init sequence questions
- From: Beinan Li <email@hidden>
- Date: Wed, 13 Feb 2013 12:14:15 -0500
Please see the original issue quoted about crashing in AUGraph init sequence.
The crash happens in AUGraphInitialize() on particular machines whenever the matrix mixer node is registered to an input callback beforehand.
I have several general questions regarding AUGraph initialization:
- Order sensitivity: I have seen quite a few sample codes seems that the initialization sequence calls have to be put in an order that roughly looks like this: NewAUGraph() => AUGraphAddNode(), AUGraphAddNode(), ..., => GraphConnectNodeInput() => AUGraphOpen() => AUGraphNodeInfo(), AUGraphNodeInfo(), ..., various set properties on nodes etc., ...AUGraphInitialize(). Now my question: must this order be absolutely respected??
- Callback registration location: In the sequence above, when should I insert callback registration code? Before AUGraphOpen or after, for instance.
- What's the difference between an "input callback" and a "render callback"? What is the effect of registering an input callback to a matrix mixer and what about a render callback?
- What's the difference between APIs AUGraphAddRenderNotify() and AUGraphSetNodeInputCallback() other than the fact that they register input/render callbacks respectively? thread safety, order in the init sequence, e.g.?
I would greatly appreciate if someone can share the knowledge because I found the info quite hard to find elsewhere.
Thanks!
On Tue, Feb 12, 2013 at 2:01 PM, Beinan Li
<email@hidden> wrote:
I've narrowed this problem down a little more:
We have only two nodes in the graph, a MatrixMixer node and an Output node.
If I register a callback to the MatrixMixer node, there will be a crash,
but if the callback is registered to the Output node, no crash.
The callback description looks like this
AURenderCallbackStruct callback = {0};
callback.inputProc = MixerInputProc;
inputCallbackProc.inputProcRefCon = this;
Does anyone know quirks about setting callbacks to nodes, such as threading or memory requirements?
Thanks!
On Tue, Feb 12, 2013 at 9:56 AM, Beinan Li
<email@hidden> wrote:
Hello,
Our Mac app crashes in AUGraphInitialize() with this backtrace from gdb
(gdb) bt
#0 0x7004dc2f in PowerMeter::PowerMeter ()
#1 0x70073583 in MatrixMixerCore::MatrixMixerCore ()
#2 0x700461ac in AUMatrixMixer::Initialize ()
#3 0x7000541b in AUBase::DoInitialize ()
#4 0x700a333d in AUMethodInitialize ()
#5 0x91e6056c in _AT_AudioUnitInitialize ()
#6 0x91e75072 in AudioUnitNodeInfo::Initialize ()
#7 0x91e76a62 in AudioUnitGraph::Initialize ()
#8 0x91e77ded in AUGraphInitialize ()
#9 0x008908b6 in CMyCoreAudioWrapper::Init (this=0xc800c80) at MyCoreAudioWrapper:829
...
#18 0x0000c9b7 in main (argc=4, argv=0xbffff8c4) at main.h:7
This crash only happens on certain machines, e.g., Mac Pro early 2008, Lion,
and not on others, e.g., Mac Mini late 2012, Mountain Lion. But we don't have
the resources to test all possible operating environments.
I cannot reveal all the callstack due to NDA.
If I disable my CoreAudio subsystem then the crash is gone.
I have trouble finding the crash in the wrapper code.
Any tips are appreciated. My current concern: Could this be related to stack corruption
due to too deep a call chain (18 levels)? It certainly doesn't look like a memory corruption from the
app side since removing the CoreAudio wrapper makes the crash disappear and the app runs fine
afterwards.
Thanks!
_______________________________________________
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