Getting couldn't render output unit -50 for cases using audio in about novocaine HOT 45 CLOSED

I had this too, and it started spontaneously. I have NO idea why it's there, and it's particular to novocaine (older core audio projects of mine work fine).

I am stumped. As the maintainer of this project, I wish I had more time to dig into all these issues. If you figure this out, I'd love nothing more than a pull request with a fix.

On Saturday, August 11, 2012 at 1:33 AM, Tony Kirke wrote:

Device is fine but simulator always gives this error. Tried on Xcode 4.3 and 4.4 and on different MacBooks. Anyone else see this?

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

from novocaine.

I spent a while trying to debug this last night but got nowhere. First couple of calls to interrupt/callback routine were ok but then it went bad. Yes, I thought this was fine before but I didn't know if I changed anything that may have caused this - so i checked out the latest novocaine and also saw it. In the process of debugging this i upgraded Xcode to 4.4 but it was bad before upgrading. I thought that before the audio data type was float in simulator compared to SInt16 on ios, but I can't rely on memory totally. I vaguely remember because I thought it was odd it wasn't the same (although it may be the number of input channels which is always 2 on simulator but 1 on device).

from novocaine.

I may be allowing the audio session to choose the audio format, but I thought that I checked for whether it was float or SInt16. FWIW, it works on my Mac Pro in the simulator. Very strange.
Also, other kinds of audio errors on my Macbook Air popped up simultaneously. I upgraded to Mountain Lion, and still saw the error. Totally reinstalled Xcode and still saw the error.

It arose spontaneously, and I cannot figure out the source. Super weird.

On Aug 11, 2012, at 3:41 PM, Tony Kirke wrote:

I spent a while trying to debug this last night but got nowhere. First couple of calls to interrupt/callback routine were ok but then it went bad. Yes, I thought this was fine before but I didn't know if I changed anything that may have caused this - so i checked out the latest novocaine and also saw it. In the process of debugging this i upgraded Xcode to 4.4 but it was bad before upgrading. I thought that before the audio data type was float in simulator compared to SInt16 on ios, but I can't rely on memory totally. I vaguely remember because I thought it was odd it wasn't the same (although it may be the number of input channels which is always 2 on simulator but 1 on device).

—
Reply to this email directly or view it on GitHub.

from novocaine.

Seems like default format on 4s & 3gs now is float. I forced same format on simulator but still got -50. If formats are OK, I can only think of either buffer leak/overrun or just audio driver weirdness

from novocaine.

-50 in my experience has always been the result of a poorly configured or under-configured audio unit. My guess is that somewhere I was lazy and didn't set something, assuming the defaults would work forever, and now the defaults are different, and now things break.

On Saturday, August 11, 2012 at 10:28 PM, Tony Kirke wrote:

Seems like default format on 4s & 3gs now is float. I forced same format on simulator but still got -50. If formats are OK, I can only think of either buffer leak/overrun or just audio driver weirdness

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

from novocaine.

Thanks Alex, tried a few more things but still couldn't resolve. By the
way, thanks for putting this library on github. Wish I knew a better way to
debug this rather than trial and error. Too bad you can get a format error
but not indication of the correct format.

On Sat, Aug 11, 2012 at 8:02 PM, Alex Wiltschko [email protected]:

-50 in my experience has always been the result of a poorly configured or
under-configured audio unit. My guess is that somewhere I was lazy and
didn't set something, assuming the defaults would work forever, and now the
defaults are different, and now things break.

On Saturday, August 11, 2012 at 10:28 PM, Tony Kirke wrote:

Seems like default format on 4s & 3gs now is float. I forced same format
on simulator but still got -50. If formats are OK, I can only think of
either buffer leak/overrun or just audio driver weirdness

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

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-7672386.

from novocaine.

From stepping through the code in inputCallback, the -50 error happens on the simulator when the parameter inNumberFrames == 471 instead of 470
if I add:
if( inNumberFrames == 471 )
inNumberFrames = 470;
Then the app runs fine and everything works. So something is messing up the number of frames on the simulator.

from novocaine.

Weird. Any ideas as to why the simulator may be adding a frame? Perhaps not setting a desired latency would help?

On Monday, August 27, 2012 at 1:20 PM, Corey wrote:

From stepping through the code in inputCallback, the -50 error happens on the simulator when the paramter inNumberFrames == 471 instead of 470
if I add:
if( inNumberFrames == 471 )
inNumberFrames = 470;
Then the app runs fine and everything works. So something is messing up the number of frames on the simulator.

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

from novocaine.

Will step through and see if I can find out why. "On my machine" this happens on the third time the inputCallback is called. I'll let you know what I find out!

from novocaine.

Awesome, looking forward to the detective work!

On Monday, August 27, 2012 at 1:53 PM, Corey wrote:

Will step through and see if I can find out why. "On my machine" this happens on the third time the inputCallback is called. I'll let you know what I find out!

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

from novocaine.

thanks too. I was also seeing problem on 2nd or 3rd callback (believe it was the 3rd)

from novocaine.

Okay, I found a culprit:

Need this at the top of novocaine.m

#include "TargetConditionals.h"

In Novocaine::setupAudio()
The simulator doesn't appear to like the bufferduration setting, so wrap that bit of code in a conditional test:

#if !TARGET_IPHONE_SIMULATOR
Float32 preferredBufferSize = 0.0232;
CheckError( AudioSessionSetProperty(kAudioSessionProperty_PreferredHardwareIOBufferDuration, sizeof(preferredBufferSize), &preferredBufferSize), "Couldn't set the preferred buffer duration");
#endif

from novocaine.

It solves it? If so, I'd love a pull request! Feels close!

On Monday, August 27, 2012 at 4:24 PM, Corey wrote:

Okay, I found a culprit:
Need this at the top of novocaine.h
#include "TargetConditionals.h"
In Novocaine::setupAudio()
The simulator doesn't appear to like the bufferduration setting.
So:
#if !TARGET_IPHONE_SIMULATOR
Float32 preferredBufferSize = 0.0232;
CheckError( AudioSessionSetProperty(kAudioSessionProperty_PreferredHardwareIOBufferDuration, sizeof(preferredBufferSize), &preferredBufferSize), "Couldn't set the preferred buffer duration");
#endif

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

from novocaine.

Done!

from novocaine.

I guess I should have elaborated:
That conditional test which does not call the AudioSessionSetProperty on the simulator does indeed make that error go away.

from novocaine.

This solves the problem on the playback side, but not on the recording side. Still getting the -50, even without setting the preferred latency. Looking into it...

from novocaine.

So, the hardware input and output latencies on the simulator are fixed at a flat 0.01 seconds. This is unusual, as on the device, it's usually much, much shorter.

Also, setting the preferred buffer IO size doesn't seem to affect the actual buffer size. I do not know what the problem is here, where the inflexibility lies.

So, to reiterate, this is fixed if you're PLAYING audio, but not if you're RECORDING audio.

from novocaine.

thanks for update

On Aug 31, 2012, at 5:58 AM, Alex Wiltschko [email protected] wrote:

So, the hardware input and output latencies on the simulator are fixed at a flat 0.01 seconds. This is unusual, as on the device, it's usually much, much shorter.

Also, setting the preferred buffer IO size doesn't seem to affect the actual buffer size. I do not know what the problem is here, where the inflexibility lies.

So, to reiterate, this is fixed if you're PLAYING audio, but not if you're RECORDING audio.

—
Reply to this email directly or view it on GitHub.

from novocaine.

I'm not getting an error recording on either device or simulator, but I am getting pretty garbled recordings -- proper pitch, but really choppy sound on the both device and simulator. On the device, when I call the recording-stop function, sometimes the last sound loops, and sometimes the sounds being recorded will also contain portions that loop.

from novocaine.

Is this new?

On Aug 31, 2012, at 1:16 PM, Corey wrote:

I'm not getting an error recording on either device or simulator, but I am getting pretty garbled recordings -- proper pitch, but really choppy sound on the both device and simulator. On the device, when I call the recording-stop function, sometimes the last sound loops, and sometimes the sounds being recorded will also contain portions that loop.

—
Reply to this email directly or view it on GitHub.

from novocaine.

Got it working on both simulator and device, with your latest code! One note though, still need to have a way to tell the filereader to stop playing when the clip is finished, instead of looping the last second or so.

I had to change AudioFileReader::stop() as follows:
- (void)stop
{
// Release the dispatch timer because it holds a reference to this class instance
[self pause];
if (self.callbackTimer) {
// dispatch_suspend(self.callbackTimer);
// dispatch_suspend(self.callbackTimer);
dispatch_release(self.callbackTimer);
}
}

or else it would crash with a memory exception. Also, in novocaine::inputCallback() I used a hack for something I noticed earlier when debugging, but still don't know why this matters. So, it's still a hack, but it seems to make it work.

if( inNumberFrames == 471 ) // the inNumberFrames off-by-one still happens. Apparently this is normal and causes garbled sound for people using pure core audio //
    inNumberFrames = 470;
CheckError( AudioUnitRender(sm.inputUnit, ioActionFlags, inTimeStamp, inOutputBusNumber, inNumberFrames, sm.inputBuffer), "Couldn't render the output unit");

from novocaine.

Got the auto-stopping working (don't know if this is desired general behavior, but for anyone interested):

AudioFileReader::bufferNewAudio()
...

    if ((self.currentFileTime - self.duration) < 0.01 && framesRead == 0)
 {
//        self.currentTime = 0.0f;
        [self stop];
        ringBuffer->Clear();
 }

Then, in my AudioManager::PlayRecordingAtPath:(NSString*)path

...

[mNVAudioManager setOutputBlock:^(float *outData, UInt32 numFrames, UInt32 numChannels) {    
    if( [mAudioReader playing] )
    {
        [mAudioReader retrieveFreshAudio:outData numFrames:numFrames numChannels:numChannels];
    }
    else {
        if( isDone == true )
        {
            [mNVAudioManager setOutputBlock:^(float *outData, UInt32 numFrames, UInt32 numChannels) {}]; // stop trying to play anything //
            memset(outData, 0, numFrames * numChannels * sizeof(float)); // nuke the remaining sound buffer since it'll just have noise in it //
            isDone = false;
            [self StopPlaying];                
        }
        else 
        {
            // there's still one more buffer left to play before shutting down the player //
            [mAudioReader retrieveFreshAudio:outData numFrames:numFrames numChannels:numChannels];
            isDone = true;    
        }            
    }
}];

from novocaine.

For the auto-stopping, can you make a pull request? That sounds like good default behavior.

Do not include the numFrames == 471 hack, though.

On Aug 31, 2012, at 6:19 PM, Corey [email protected] wrote:

Got the auto-stopping working (don't know if this is desired general behavior, but for anyone interested):

AudioFileReader::bufferNewAudio()
...

if ((self.currentFileTime - self.duration) < 0.01 && framesRead == 0) {
// self.currentTime = 0.0f;
[self stop];
ringBuffer->Clear();
}

—
Reply to this email directly or view it on GitHub.

from novocaine.

Sure thing. The way I implemented it, it will still require that people modify their output block to stop playing on their end, otherwise it will continuously play the sound in the last buffer (if that's what their output block is doing), so there should probably be a comment about that in the readme somewhere.

from novocaine.

Ah, works on the iPhone without the 471 check.
From what I could find, it seems like the simulator uses the Mac's settings, which has a sampling rate of 48000. People say to change that to 44,100, but that isn't a setting I can find on Lion. Apparently setting OSX to use 44100 fixes this particular issue in the simulator.

Edit: After finding the Audio Midi Setup in Utilities, I changed the speaker output to 44100 Hz, but that did not affect the simulator -50 issue. Since it's just on the simulator, I won't create a pull request for the 471 hack, but here's a simulator-only version of it:

Novocaine::inputCallback()
{
   ...
   // Check the current number of channels
   // Let's actually grab the audio
#if TARGET_IPHONE_SIMULATOR
 // this is a workaround for an issue with core audio on the simulator, //
//  likely due to 44100 vs 48000 difference in OSX //
    if( inNumberFrames == 471 )
        inNumberFrames = 470;
#endif
    CheckError( AudioUnitRender(sm.inputUnit, ioActionFlags, inTimeStamp, inOutputBusNumber, inNumberFrames, sm.inputBuffer), "Couldn't render the output unit");
   ...
}

Woohoo! Found out how to make a code block in here, on purpose! Three backquotes in a row at in the beginning and the end of the code block.

from novocaine.

Interesting, hadn't thought to check sampling rate. I'll look into that soon.
On Aug 31, 2012, at 8:43 PM, Corey [email protected] wrote:

Ah, works on the iPhone without the 471.
From what I could find, it seems like the simulator uses the Mac's settings, which has a sampling rate of 48000. People say to change that to 44,100, but that isn't a setting I can find on Lion. Apparently setting OSX to use 44100 fixes this particular issue in the simulator.

—
Reply to this email directly or view it on GitHub.

from novocaine.

Any updates to this?

from novocaine.

I haven't touched the Novocaine source in awhile, and I'm not sure if there's anybody out there who wants to dig into the core. Is there? I'd love to provide support and advice to anybody interested.

On Thursday, November 29, 2012 at 10:01 AM, Ross Cairns wrote:

Any updates to this?

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

from novocaine.

Well I would be happy to help if I can. But what is the situation... @casbreuk's fix here works AFAIK and is conditional for the simulator. I am happy to put the fix in a pull request so this issue can be closed. But you mention it is a hack? I am sure I can't be the only one who hits this issue so it would be great to have it resolved!

from novocaine.

If I remember right, it is a hack. But, if it's a consistently-working hack, I'll pull it in. Can you test it and make a pull request?

On Nov 29, 2012, at 10:51 AM, Ross Cairns [email protected] wrote:

Well I would be happy to help if I can. But what is the situation... @casbreuk's fix here works AFAIK and is conditional for the simulator. I am happy to put the fix in a pull request so this issue can be closed. But you mention it is a hack? I am sure I can't be the only one who hits this issue so it would be great to have it resolved!

—
Reply to this email directly or view it on GitHub.

from novocaine.

i havent seen or tried that hack, but would also be willing to test and verify after its pulled in
Thanks!
Tony

On Nov 29, 2012, at 7:54 AM, Alex Wiltschko [email protected] wrote:

If I remember right, it is a hack. But, if it's a consistently-working hack, I'll pull it in. Can you test it and make a pull request?

On Nov 29, 2012, at 10:51 AM, Ross Cairns [email protected] wrote:

Well I would be happy to help if I can. But what is the situation... @casbreuk's fix here works AFAIK and is conditional for the simulator. I am happy to put the fix in a pull request so this issue can be closed. But you mention it is a hack? I am sure I can't be the only one who hits this issue so it would be great to have it resolved!

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from novocaine.

Hi Tony, if you want to try break it you can checkout out this repo/branch https://github.com/rc1/novocaine/tree/fix-ios-simulator

from novocaine.

Thanks. Fixed the problem for me!
Tony

On Thu, Nov 29, 2012 at 8:31 AM, Ross Cairns [email protected]:

Hi Tony, if you want to try break it you can checkout out this repo/branch
https://github.com/rc1/novocaine/tree/fix-ios-simulator

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-10855153.

from novocaine.

If this is fixed, can someone issue a pull request?

On Nov 30, 2012, at 3:43 AM, Tony Kirke [email protected] wrote:

Thanks. Fixed the problem for me!
Tony

On Thu, Nov 29, 2012 at 8:31 AM, Ross Cairns [email protected]:

Hi Tony, if you want to try break it you can checkout out this repo/branch
https://github.com/rc1/novocaine/tree/fix-ios-simulator

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-10855153.

—
Reply to this email directly or view it on GitHub.

from novocaine.

I put the pull request above yesterday...

from novocaine.

I don't see a pull request on my version of the project. Can you resubmit?

from novocaine.

are you viewing it on github? you should be able to just merge in the attached reference.... if not I will issue a pull later today...

Ross Cairns

www.theworkers.net (http://www.theworkers.net/)

www.rosscairns.com (http://www.rosscairns.com/)

07751244728

twitter: @RossC1

On Friday, 30 November 2012 at 08:59, Alex Wiltschko wrote:

I don't see a pull request on my version of the project. Can you resubmit?

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

from novocaine.

I'd much appreciate it if you issue the pull request. No rush.

On Nov 30, 2012, at 4:01 AM, Ross Cairns [email protected] wrote:

are you viewing it on github? you should be able to just merge in the attached reference.... if not I will issue a pull later today...

Ross Cairns

www.theworkers.net (http://www.theworkers.net/)

www.rosscairns.com (http://www.rosscairns.com/)

07751244728

twitter: @RossC1

On Friday, 30 November 2012 at 08:59, Alex Wiltschko wrote:

I don't see a pull request on my version of the project. Can you resubmit?

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

—
Reply to this email directly or view it on GitHub.

from novocaine.

I don't want to bump this thread hard, but I'm having the same issue on my iPad 4.. It works fine on my iPhone, but on the iPad 4 it keeps giving -50 error.
I use the latest framework hooked together with NVDSP framework for filtering. But the error is on this line -> (711) CheckError( AudioUnitRender(sm.inputUnit, ioActionFlags, inTimeStamp, inOutputBusNumber, inNumberFrames, sm.inputBuffer), "Couldn't render output");
But still gives quite accurate callbacks. it's clogging my log, so for now I decided to add an check if it's error != -50. But I'm really interested in what could cause the issue since I can't find alot about it.

from novocaine.

Had the same problem, Error: Couldn't render the output unit (-50)
but playing with HeadsetBT a bluetooth headset. It’s sampling rate was 16000.000000,
and it seemed to be alternating inNumberFrames between 706 and 705. So I added this code to workaround the error message.
if( inNumberFrames == 706 ) inNumberFrames = 705;

just before the

CheckError( AudioUnitRender(sm.inputUnit, ioActionFlags, inTimeStamp, inOutputBusNumber, inNumberFrames, sm.inputBuffer), "Couldn't render the output unit");

from novocaine.

Getting Couldn't render the output unit (-50),
When working with only Bluetooth HeadsetBT working fine but at the same time when attached cable headphone getting this problem. could not find any solution can anyone help.

from novocaine.

Still an issue with recording block on a latest osx + iphone 6 simulator. Happened the first time in several weeks. Restart doesn't help.

from novocaine.

I found one problem in audio processing. In simulator it's works fine but problem in iOS devices.

Audio File :https://www.dropbox.com/s/1eybs11wog8v3rz/Policemen%20%26%20Pirates.mp3?dl=0

After 5 second there is guitar sound for 4-5 seconds. That guitar sound missing in iOS device.

If any one help me then it would be great.

Thanks in advance.

from novocaine.

I just encountered a similar problem with both an iPhone 6S and a new iPad mini. In this case iNumberFrames was occasionally 236, and forcing it to 235 solved the problem.

from novocaine.

        ThanksI'll try and let you know.---- On Mon, 16 May 2016 08:24:38 -0400  Andy Haith<[email protected]> wrote ----I just encountered a similar problem with both an iPhone 6S and a new iPad mini. In this case iNumberFrames was occasionally 236, and forcing it to 235 solved the problem.  —You are receiving this because you commented.Reply to this email directly or view it on GitHub            

from novocaine.