I figured out what the problem was with the Asserts in AVAudioMixerSample.
The Apple AVAudioMixerSample project and OTHER Apple AVAudioEngine related sample projects (this definitely applies also to the project with the bouncing balls inside the box, with the 3D spatial sounds) need a code revision!
Whoever wrote this code, utilized NSAssert in a way that prevents these projects from compiling, or running if Asserts are turned OFF in Build Settings. This is not a proper way to utilize NSAssert. NSAssert statements should only run if Asserts are turned ON in Build Settings, they should NOT prevent program functionality if they are turned OFF in Build Settings (which is the standard setting for Release Builds). The Apple written code makes Asserts mandatory for the app to function at all..
Below are two examples of the problematic usage of NSAssert in AVAudioMixerSample. Each example shows modifications that eliminate critical code from being embedded into NSAssert statements. Every NSAssert statement in the project needs similar revision as shown below.
Apple's code that only functions with NSAssert enabled:
NSError *error;
NSAssert([_engine startAndReturnError:&error], @"couldn't start engine, %@", [error localizedDescription]);
Correct usage of NSAssert to start the engine, even if Asserts are turned OFF:
NSError *error;
BOOL success;
success = [_engine startAndReturnError:&error];
NSAssert(success, @"couldn't start engine, %@", [error localizedDescription]);
Apple's code that only functions with NSAssert enabled:
NSError *error;
// load marimba loop
NSURL *marimbaLoopURL = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"marimbaLoop" ofType:@"caf"]];
AVAudioFile *marimbaLoopFile = [[AVAudioFile alloc] initForReading:marimbaLoopURL error:&error];
_marimbaLoopBuffer = [[AVAudioPCMBuffer alloc] initWithPCMFormat:[marimbaLoopFile processingFormat] frameCapacity:(AVAudioFrameCount)[marimbaLoopFile length]];
NSAssert([marimbaLoopFile readIntoBuffer:_marimbaLoopBuffer error:&error], @"couldn't read marimbaLoopFile into buffer, %@", [error localizedDescription]);
Correct usage of NSAssert to read AVAudioFile into the AVAudioPCMBuffer, even if Asserts are turned OFF:
NSError *error;
BOOL success;
// load marimba loop
NSURL *marimbaLoopURL = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"marimbaLoop" ofType:@"caf"]];
AVAudioFile *marimbaLoopFile = [[AVAudioFile alloc] initForReading:marimbaLoopURL error:&error];
_marimbaLoopBuffer = [[AVAudioPCMBuffer alloc] initWithPCMFormat:[marimbaLoopFile processingFormat] frameCapacity:(AVAudioFrameCount)[marimbaLoopFile length]];
success = [marimbaLoopFile readIntoBuffer:_marimbaLoopBuffer error:&error];
NSAssert(success, @"couldn't read marimbaLoopFile into buffer, %@", [error localizedDescription]);
NOTE: My previous comments regarding stopping an AVAudioPlayerNode cleanly from a loop still stand! I still consider this to be a bug in AVAudioEngine..
The remaining desired functionality is:
-(void) playLoop1PlayerNode {
[self startEngine];
[_loop1Player scheduleBuffer:_loop1Buffer atTime:nil options:AVAudioPlayerNodeBufferLoops completionHandler:nil];
[AVAudioPlayerNode play];
}
-(void) stopLoop1PlayerNode {
[AVAudioPlayerNode stop]; // NO POP HEARD, even when stopping low frequency audio sample playback.
}
Toggling the AVAudioPlayerNode's volume property from 0.0 to desired value does NOT produce a Pop. Calling stop on the AVAudioPlayerNode, should NOT produce a Pop either (Doing this currently does produce a Pop if the looping sample, in the buffer, is low frequency).