meirm February 2016

Crackling audio due to wrong audio data

I'm using CoreAudio low level API for audio capturing. The app target is MAC OSX, not iOS.

During testing it, from time to time we got very annoying noise modulate with real audio. the phenomena develops with time, started from barely noticeable and become more and more dominant.

Analyze the captured audio under Audacity indicate that the end part of the audio packet is wrong.

Here are sample picture: enter image description here

the intrusion repeat every 40 ms which is the configured packetization time (in terms of buffer samples)

Update: Over time the gap became larger, here is another snapshot from the same captured file 10 minutes later. the gap now contains 1460 samples which is 33ms from the total 40ms of the packet!! enter image description here

CODE SNIPPESTS:

capture callback

OSStatus MacOS_AudioDevice::captureCallback(void *inRefCon,
                                            AudioUnitRenderActionFlags *ioActionFlags,
                                            const AudioTimeStamp *inTimeStamp,
                                            UInt32 inBusNumber,
                                            UInt32 inNumberFrames,
                                            AudioBufferList *ioData)
{
    MacOS_AudioDevice* _this = static_cast<MacOS_AudioDevice*>(inRefCon);

    // Get the new audio data
    OSStatus err = AudioUnitRender(_this->m_AUHAL, ioActionFlags, inTimeStamp, inBusNumber, inNumberFrames, _this->m_InputBuffer);
    if (err != noErr)
    {
        ...

        return err;
    }

    // ignore callback on unexpected buffer size
    if (_this->m_params.bufferSizeSamples != inNumberFrames)
    {
        ...

        return noE        

Answers


hotpaw2 February 2016

Periodic glitches or dropouts can be caused by not paying attention to or by not fully processing the number of frames sent to each audio callback. Valid buffers don't always contain the expected or same number of samples (inNumberFrames might not equal bufferSizeSamples or the previous inNumberFrames in a perfectly valid audio buffer).

It is possible that these types of glitches might be caused by attempting to record at 44.1k on some models of iOS devices that only support 48k audio in hardware.

Some types of glitch might also be caused by any non-hard-real-time code within your m_callbackFunc function (such as any synchronous file reads/writes, OS calls, Objective C message dispatch, GC, or memory allocation/deallocation).

Post Status

Asked in February 2016
Viewed 1,713 times
Voted 13
Answered 1 times

Search




Leave an answer