Changing PreferredBufferDuration at runtime results in -50 AudioUnitRender OSStatus
Changing PreferredBufferDuration at runtime results in -50 AudioUnitRender OSStatus
- Subject: Changing PreferredBufferDuration at runtime results in -50 AudioUnitRender OSStatus
- From: Alexander Bollbach <email@hidden>
- Date: Tue, 16 Feb 2016 00:38:42 +0000
I posted about this on Stack Overflow but have done some reading since and still can't get rid of this crash.
Original Question.I'm writing a waveform display for iOS 9.2. At the moment, a very simple app that renders red lines from left to right for each frame buffer. If the frame buffer is 1024 frames per render callback than I make use of most pixels on my iphone6+ but I can set it to 16 frames per buffer and each line is draw 1080pixels/16 points apart. (the waveform's are displayed over the portrait axis on the left side). Thats the idea.
So I can launch the app and if I specify any initial preferred buffer duration (for example. 0.0001) everything works. But trying to switch dynamically from my UI at runtime results in the -50 crash at the AudioUnitRender() call in my remoteIO's input callback. I have read the AudioSession programming guide for AVFoundation from Apple's online documentation and cannot figure out what to do.
I've tried re-activating the audioSession in the NSNotification Callback like this:
//////////////////////////////// handle Change of preferredBufferDuration /////
- (void)handleRouteChange:(NSNotification *)notification {
NSError *audioSessionError = nil;
AVAudioSession *session = [AVAudioSession sharedInstance];
[session setActive:YES error:&audioSessionError];
if (audioSessionError) {
NSLog(@"Error %ld, %@",
(long)audioSessionError.code, audioSessionError.localizedDescription);
}
CheckError(AudioOutputUnitStart(self.remoteIOUnit), "stop unit in mode");
}
////////////// end
(I actually stop RemoteIO from running because AVAudioSession want's no running I/O when you disable it) But this results in an infinite loop, because changing the AudioSession actually triggers another "handleRouteChanged:" notification.
I'm sure there is some regular way to deal with changing audioSession parameters on the fly with regards to I/O AudioUnits.
_______________________________________________
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