You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If noteOn events are called while loading AudioKit's AppleSampler() it can occasionally crash on line 121 of DSPBase.mm. Here is a test project to illustrate the crash: https://github.com/NickCulbertson/TestRenderBlock
Just a thought, but this is Apple's generated render block in DSPKernel when making an AUv3. It might be useful for comparison:
// MARK: - AUAudioUnit (AUAudioUnitImplementation)
// Subclassers must provide a AUInternalRenderBlock (via a getter) to implement rendering.
- (AUInternalRenderBlock)internalRenderBlock {
/*
Capture in locals to avoid ObjC member lookups. If "self" is captured in
render, we're doing it wrong.
*/
// Specify captured objects are mutable.
__block OverdriveSynthDSPKernel *state = &_kernel;
__block BufferedInputBus *input = &_inputBus;
return ^AUAudioUnitStatus(AudioUnitRenderActionFlags *actionFlags,
const AudioTimeStamp *timestamp,
AVAudioFrameCount frameCount,
NSInteger outputBusNumber,
AudioBufferList *outputData,
const AURenderEvent *realtimeEventListHead,
AURenderPullInputBlock __unsafe_unretained pullInputBlock) {
AudioUnitRenderActionFlags pullFlags = 0;
if (frameCount > state->maximumFramesToRender()) {
return kAudioUnitErr_TooManyFramesToProcess;
}
AUAudioUnitStatus err = input->pullInput(&pullFlags, timestamp, frameCount, 0, pullInputBlock);
if (err != noErr) { return err; }
AudioBufferList *inAudioBufferList = input->mutableAudioBufferList;
/*
Important:
If the caller passed non-null output pointers (outputData->mBuffers[x].mData), use those.
If the caller passed null output buffer pointers, process in memory owned by the Audio Unit
and modify the (outputData->mBuffers[x].mData) pointers to point to this owned memory.
The Audio Unit is responsible for preserving the validity of this memory until the next call to render,
or deallocateRenderResources is called.
If your algorithm cannot process in-place, you will need to preallocate an output buffer
and use it here.
See the description of the canProcessInPlace property.
*/
// If passed null output buffer pointers, process in-place in the input buffer.
AudioBufferList *outAudioBufferList = outputData;
if (outAudioBufferList->mBuffers[0].mData == nullptr) {
for (UInt32 i = 0; i < outAudioBufferList->mNumberBuffers; ++i) {
outAudioBufferList->mBuffers[i].mData = inAudioBufferList->mBuffers[i].mData;
}
}
state->setBuffers(inAudioBufferList, outAudioBufferList);
state->processWithEvents(timestamp, frameCount, realtimeEventListHead, nil /* MIDIOutEventBlock */);
return noErr;
};
}
The text was updated successfully, but these errors were encountered:
The only info we get is the error code -10879, kAudioUnitErr_InvalidProperty. However, it's difficult to know what causes the connection source in the component to be invalid because we don't know what the sampler does in its internal method, loadInstrument(at instrumentURL: URL).
Yeah, I just didn't know if we needed to add a return somewhere in the render block to avoid trying to render a null object. Unfortunately, it is difficult to recreate the specific errors I was seeing from it in production but it usually centered around trying to play notes right before or soon after changing AVAudioUnitSampler instruments. I'll reopen it is I get more info.
macOS Version(s) Used to Build
macOS 12 Monterey
Xcode Version(s)
Xcode 13.4.1
Description
If noteOn events are called while loading AudioKit's AppleSampler() it can occasionally crash on line 121 of DSPBase.mm. Here is a test project to illustrate the crash: https://github.com/NickCulbertson/TestRenderBlock
This is the current AUInternalRenderBlock:
Just a thought, but this is Apple's generated render block in DSPKernel when making an AUv3. It might be useful for comparison:
The text was updated successfully, but these errors were encountered: