Crash : EZAudioUtilities RMS:length:

[nicole1314]

Thread : Crashed: com.apple.main-thread 0 EZAudio 0x1012a06 +[EZAudioUtilities RMS:length:] + 9 1 EZAudio 0x1012f5d +[EZAudioUtilities appendBufferRMS:withBufferSize:toHistoryInfo:] + 36 2 EZAudio 0x1010e0d -[EZAudioPlot updateBuffer:withBufferSize:] + 72 3 StethoCloud 0x2312938 _TPATFFC11StethoCloud16StethoController10microphoneFS0_FTCSo12EZMicrophone16hasAudioReceivedGVSs20UnsafeMutablePointerGS2_Sf14withBufferSizeVSs6UInt3220withNumberOfChannelsS3__T_U_FTT + 120 4 libdispatch.dylib 0x347a3e2f _dispatch_call_block_and_release + 10 5 libdispatch.dylib 0x347a3e1b _dispatch_client_callout + 22 6 libdispatch.dylib 0x347a86c9 _dispatch_main_queue_callback_4CF + 1532 7 CoreFoundation 0x226cc535 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 8 8 CoreFoundation 0x226caa2f __CFRunLoopRun + 1590 9 CoreFoundation 0x2261d0d9 CFRunLoopRunSpecific + 516 10 CoreFoundation 0x2261cecd CFRunLoopRunInMode + 108 11 GraphicsServices 0x2b992af9 GSEventRunModal + 160 12 UIKit 0x268a62dd UIApplicationMain + 144 13 CliniCloud 0x2475a4 main (AppDelegate.swift:17) 14 libdyld.dylib 0x347cc873 start + 2

[nicole1314]

We also experiencing the same issue as #251 .

[zbencz3]

any ideas why? I have this issue keep popping back.

[nicole1314]

@zbencz3 I have no idea. Do you find anything might be helpful?

[zbencz3]

No. I can't reproduce it myself, but the end users experience it sometimes.

[nicole1314]

@zbencz3 I tried to debug. When it happens, the buffer is 0 and the buffersize is 1024.

[zbencz3]

and what triggers it? easy to reproduce it for you?

[nicole1314]

@zbencz3 One out of 10 times I will get the crash.

[syedhali]

@nicole1314 when the buffer is 0, is it NULL or does the buffer actually exist in memory? Seems like the buffer might be getting deallocated before entering this function. If you're using one of the EZAudio delegate functions and using anything besides the audioReceived float buffers provided then there's a chance those Core Audio provided buffers are being deallocated before the RMS calculation is performed. The EZMicrophone copies the audio data from the Audio Unit callback into the float buffers, which are not freed until the whole EZMicrophone instance is deallocated.

[zbencz3]

this is how it looks in my case. So deallocated I presume. Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0xe000000012d963e6

[nicole1314]

@syedhali Buffer is a pointer so the buffer is not in the memory. We are using hasAudioReceived for the plot and hasBufferList for the recording.

public func microphone(microphone: EZMicrophone, hasAudioReceived buffer: UnsafeMutablePointer<UnsafeMutablePointer>, withBufferSize bufferSize: UInt32, withNumberOfChannels numberOfChannels: UInt32)

public func microphone(microphone: EZMicrophone, hasBufferList bufferList: UnsafeMutablePointer, withBufferSize bufferSize: UInt32, withNumberOfChannels numberOfChannels: UInt32)

[zbencz3]

@nicole1314 do you use tag 1.1.2 ?

[nicole1314]

@zbencz3 What do you mean by tag 1.1.2?

[zbencz3]

I am trying to see if that's the latest code usable..

[zbencz3]

does the new update help you? 1.1.4

[nicole1314]

@zbencz3 I changed the tag from 1.1.2 to 1.1.4. I still have RMS crash. How about you?

[lluisgerard]

The only workaround I found to fix this in my code is to check for the microphone delegate before sending the buffer around. Tested with 1.1.5

That's because on my EZRecorderDelegate -> recorderDidClose I have:

    func recorderDidClose(recorder: EZRecorder!) {
        self.microphone?.delegate = nil
    }

And in my EZMicrophoneDelegate I just check for that delegate before sending the buffer:

    func microphone(microphone: EZMicrophone!, hasAudioReceived buffer: UnsafeMutablePointer<UnsafeMutablePointer<Float>>, withBufferSize bufferSize: UInt32, withNumberOfChannels numberOfChannels: UInt32) {
        mainqueue { [weak self] in
            guard let _ = self?.microphone?.delegate else {
                print("You shall not pass!")
                return
            }
            // Your code here to update the wave, etc...
        }
    }

• OT: the mainqueue func is just a regular dispatch_async(dispatch_get_main_queue(), closure) wrapper

[nicole1314]

@lluisgerard I tried 1.1.5 and it still crashes at line sum += buffer[i] * buffer[i]; Can you please show me how to prevent this?

• (float)RMS:(float )buffer length:(int)bufferSize { float sum = 0.0; for(int i = 0; i < bufferSize; i++) sum += buffer[i] \ buffer[i]; return sqrtf( sum / bufferSize); }

[zbencz3]

haven't had a crash for a while, but I removed ezaudio from part of the functionality until it will be figured out or I can do something about it.

[magnus80a]

I get this too when app is returned into foreground from background. I didn't see this issue and created my own #314 . Maybe it should be closed, but I have a screenshot there that might be helpful for others.

[designerfuzzi]

As the error report suggests, the error is not in -RMS:length: it happens before and the error bubbles up until the buffer is accessed while it is empty or NULL. Which must throw an BAD_ACCESS Make sure your buffer is properly set up and specially do make sure you do not access buffer that is not there..

one example this can happens is when you change the input device of EZMicrophone and choose some "Channel" to plot this specific buffer, but the number for "Channel" is maybe invalid ..

-(void)    microphone:(EZMicrophone *)microphone
     hasAudioReceived:(float **)buffer
       withBufferSize:(UInt32)bufferSize
 withNumberOfChannels:(UInt32)numberOfChannels {
    UInt32 channel = _showChannel < numberOfChannels ? _showChannel : 0; //see this safety check?
    __weak typeof (self) weakSelf = self;
    dispatch_async(dispatch_get_main_queue(), ^{
        [weakSelf.microPlot updateBuffer:buffer[channel] withBufferSize:bufferSize];
    });
}

In other words, when you try to access "channel" here out of buffer scope you very likely end up with the error this thread is talking about.

This is because EZAudio does not have channel mapping, which means there is no mechanism that keeps you from making this mistake.