Crash when launching from background while audio playing about novocaine HOT 19 CLOSED

Thanks for bringing this to my attention. I've never tested this use case before, but I'll look into it. If you have any solution in the meanwhile, please fork and make changes.

On Tuesday, June 5, 2012 at 4:19 PM, hoddez wrote:

Hi there,
First of all let me thank you for open sourcing this. It looks like a very valuable tool coming from somebody who has suffered from CoreAudio coding.

I've been checking out your library to see how robust it is in regards to backgrounding and interuptions etc.

I've found a crashing bug that initially makes me think it isn't that robust but maybe you can comment on it.

Testing on iPad 3 with iOS 5.1.
Simple app that launches a recording queue with:
audioManager = [Novocaine audioManager];
//This starts an input Block for recording. Set to audioManager.inputBlock=nil to stop
audioManager.inputBlock = ^(float *data, UInt32 numFrames, UInt32 numChannels) {
NSLog(@"stillgoing:%d",(int)numFrames);
};

I tried going in and out of background and that appears to work fine (for short term at least).

But if I send the app to background, then start playing audio from the stock Music app, then go back to the app running Novocaine I get this error in the console:
Error: Checking number of input channels ('!cat')

---

Reply to this email directly or view it on GitHub:
#15

from novocaine.

The problem is (obviously) with checking the number of input channels. Removing the section of code that does this is a workaround, but I'm guessing that code is there for a reason.

I know that you can't record audio while the stock music player is playing. So I guess that must block it from checking the number of input channels at that time. The weird thing is that if you take that out you can still record. Maybe if you check the number of channels later on in the cycle (once you've stopped the audio session from the music player).

from novocaine.

The error is thrown on the check for the number of channels, but the problem most likely stems from an expired audio session. Novocaine only initializes an audio session once, and never checks if it expires. It works this way because I'd never had to build (or thought to build) long-running audio apps.

Does removing the audio channel check actually fix the problem? I'd be surprised if it does. I think the true fix is, in - (void)checkSessionProperties to see if the audio session is still valid, and if not, to re-initialize it.

from novocaine.

Yes, removing the check for input channels only will fix the problem. I haven't checked that the audio I get makes sense but everything appears to run fine and I still get a buffer every 1024 samples.

I tried moving the checkSessionProperties later on and that doesn't seem to help.

from novocaine.

Yeah, don't worry about moving checkSessionProperties, the fix has to
happen inside of checkSessionProperties. I'll peek inside the code in a day
or two, but for now, good to hear that removing the channel check fixes
your problem. Just hold onto that for now, but I should have a more
permanent fix for you in the near future.

On Wed, Jun 6, 2012 at 8:42 AM, hoddez <
[email protected]

wrote:

Yes, removing the check for input channels only will fix the problem. I
haven't checked that the audio I get makes sense but everything appears to
run fine and I still get a buffer every 1024 samples.

I tried moving the checkSessionProperties later on and that doesn't seem
to help.

---

Reply to this email directly or view it on GitHub:
#15 (comment)

from novocaine.

Thanks. Please let me know what the proper fix is. I'd be interested to hear about it

from novocaine.

Quick follow-up: You have to be sure to manually set self.numInputChannels = 1;

otherwise you just get 0s for recorded audio

from novocaine.

I too bumped on this problem. My app crashes once there is an incoming call with the !cat message... It is simply an invalid configuration issue between the foreground app and the incoming phone call..

from novocaine.

Baskaran, did my workaround work for you in this case or does an incoming call cause a crash even with the input channel code commented out?

from novocaine.

Just an FYI, having trouble setting aside time to work on Novocaine, but I haven't forgotten about the issue.

from novocaine.

Hi guys, i also have this problem, but in my case there is simple issue repro:

1. I just present view controller,
2. than do in it
   audioManager = [Novocaine audioManager];
3. then dismiss view controller.
4. then show present this controller again
5. Crash

from novocaine.

Hi All, I have made some changes to separate the Init from the rest of the library since you can only call Init once when the application loads. I have not had time to update the sample application from the original version yet but you may want to give it a try to see if it solves your issue. On my forked version, it cleans up nicely on dealloc or when the window is closed.

from novocaine.

Also, I have not had the chance to test my mods against Mac version either! just iOS and it is ARC'ed...

from novocaine.

I found a solution:

Just add [sm pause]; to 'Begin interuption' - https://github.com/soulfly/novocaine/commit/15a0bffedcb8ea5441e7b8150d3f168a2e3ff247

from novocaine.

@soulfly That doesn't fix it for me. In fact, it would seem like that entire function is not being called(I don't get anything in the log about interruption beginning or ending) and the app still crashes sometimes when resuming from background.

from novocaine.

@raja-baz Please check my fork https://github.com/soulfly/novocaine with this fix.
It works for my project

from novocaine.

Issue a pull request if you've fixed it?

On Monday, March 4, 2013 at 10:33 AM, Igor Khomenko wrote:

@raja-baz (https://github.com/raja-baz) Please check my fork https://github.com/soulfly/novocaine with this fix.
It works for my project

—
Reply to this email directly or view it on GitHub (#15 (comment)).

from novocaine.

Audiobus provides a workaround in http://developer.audiob.us/doc/_thirty-_minute-_integration.html. The code piece is like:

UInt32 channels;
OSStatus result = AudioSessionGetProperty(kAudioSessionProperty_CurrentHardwareInputNumberChannels, &size, &channels);
if ( result == kAudioSessionIncompatibleCategory ) {
// Audio session error (rdar://13022588). Power-cycle audio session.
AudioSessionSetActive(false);
AudioSessionSetActive(true);
result = AudioSessionGetProperty(kAudioSessionProperty_CurrentHardwareInputNumberChannels, &size, &channels);
if ( result != noErr ) {
NSLog(@"Got error %d while querying input channels", result);
}
}

from novocaine.

Open pull request in a separate issue. Closing.

from novocaine.