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 ...
Contrary to @Polyphonic's answer, I don't believe this is related to the flags at all. I also wonder if @bradhowes is mistaken that the block is called before
allocateRenderResources is called. In my experience, that has not occurred.
internalRenderBlock is called every time
renderBlock is called, which can be multiple times during an audio graph setup, and will happen before the alloc method. It seems odd, but It Just Is.
Consequently, general advice for everyone is that you should make sure your block doesn't capture any variable values which are not immutable after the audio unit's initialization, otherwise those captured values can be different in different calls to
internalRenderBlock and cause subtle bugs. (Been there.) If you look at Apple's example code ("Creating Custom Audio Effects" / AUv3Filter), this is (part of) why all the state that is referred to by
internalRenderBlock is stored in a separate struct/C++ class instance; The pointer to that struct/instance never changes, as that pointer is the only thing the block captures. Any time
internalRenderBlock is called, therefore, returns the same exact block and captures and has identical behavior.
Here's some logging to show the sequence of events. The image below shows my constructor being called to create my custom AUAudioUnit. After construction, there is a solitary call to
internalRenderBlock. The audio unit is part of a graph but the graph has not been started yet.
Here are the log lines after the graph starts and audio is flowing:
There is a second call to
internalRenderBlock before my
allocateRenderResources method is invoked. When rendering starts, my audio unit's own
allocateRenderResources method is invoked, and when I call AUAudioUnit's
internalRenderBlock is called a third time. After that, no more.