Why is internalRenderBlock fetched and used before allocateRenderResources() is called?

I have a working AUv3 AUAudioUnit app extension but I had to work around a strange issue: I found that the internalRenderBlock value is fetched and invoked before allocateRenderResources() is called. I have not found any documentation stating that this would be the case, and intuitively it does not make any sense. Is there something I am doing in my code that would be causing this to be the case? Should I *force* a call to allocateRenderResources() if it has not been called before internalRenderBlock is fetched? Thanks! Brad
Up vote post of bradhowes Down vote post of bradhowes
999 views
Posted by
bradhowes
Reply

  • I spent some time on this a few years ago, so I can confirm.

    In my auv3 tutorial code I added checks to see if the cached blocks that should have been initialized in allocateRenderResources were nil or not. It worked but it has the feeling of fixing an airplane wing with bubble gum.

    —
    genedelisa

  • I have seen Gene's solution from the AU MIDI processor tutorial (thanks, BTW!), which is to duplicate a bit of the code from allocateRenderResourcesAndReturnError() to capture an instance property. Was this your workaround as well? If the render block and its captures are being fetched before what is ostensibly the render initialization for the AU, then should we force call it, or just put any init in internalRenderBlock and ignore allocateRenderResourcesAndReturnError altogether?

    —
    derelictcomputer
Add a Comment

Accepted Reply

I suggest you try logging (or otherwise examining) the AudioUnitRenderActionFlags being passed into the render proc. Some flags look like they might make sense of this behavior.
Posted by
Polyphonic
Up vote reply of Polyphonic Down vote reply of Polyphonic
Post marked as solved

  • I'm seeing the same thing as the OP, and upon inspecting the AudioUnitRenderActionFlags, I see that no flags are set. Can someone explain why this was accepted as the answer? I think I'm missing something.

    —
    derelictcomputer
Add a Comment

Replies

I suggest you try logging (or otherwise examining) the AudioUnitRenderActionFlags being passed into the render proc. Some flags look like they might make sense of this behavior.
Posted by
Polyphonic
Up vote reply of Polyphonic Down vote reply of Polyphonic
Post marked as solved

  • I'm seeing the same thing as the OP, and upon inspecting the AudioUnitRenderActionFlags, I see that no flags are set. Can someone explain why this was accepted as the answer? I think I'm missing something.

    —
    derelictcomputer
Add a Comment

I also noticed this happed when running auvaltool. As with all things AU, I find it better to err on the safe side and do (what should be unnecessary) checks in the render block. The flags can be useful but not always.

Also it's certainly a good idea to always assume the host app will do something horrible. IMHO ( and it's only my opinion) This day and age with CPUs being so much faster, it's not so bad to do a few checks at the start of the render block before proceeding with the main DSP ...

Posted by
ParanoidAndroid
Post not yet marked as solved Up vote reply of ParanoidAndroid Down vote reply of ParanoidAndroid

  • Thanks for following up on this old question. I agree completely with being defensive. I was just curious if I had missed something.

    —
    bradhowes
Add a Comment