Android Oboe library is laggy on a few devices

Issue

In my Android app, I use the Oboe library and the Vorbisfile library to extract, process and redirect audio samples to the audio output.

To keep it simple, here is a quick overview of what I've been doing (using the hello-oboe example here) :

oboe::DataCallbackResult PlayAudioEngine::onAudioReady(oboe::AudioStream *audioStream, void *audioData, int32_t numFrames)
{
    // init:
    if (mBufferSizeSelection != kBufferSizeAutomatic && audioStream->getBufferSizeInFrames() != mBufferSizeSelection * mFramesPerBurst)
    {
        audioStream->setBufferSizeInFrames(mBufferSizeSelection * mFramesPerBurst);
    }

    // audio extraction:
    if (audioStream->getFormat() == oboe::AudioFormat::Float)
    {
        // extract audio samples using vorbisfile...
        // put the extracted audio samples in audioData...
    }
    else
    {
        // extract audio samples using vorbisfile...
        // put the extracted audio samples in audioData...
    }
    return oboe::DataCallbackResult::Continue;
}

This code works like a charm on most devices (I tested it on 10+ devices, including low-end devices like Galaxy S3 mini, or Nokia 1), without any lag.

The problem is: On some devices (Archos 55 Cobalt (API 23) and OnePlus One (API 23)), the sound is quite laggy, especially if I extract 2 audio files at the same time (so I can play them simultaneously), while the very same code works without any problem on less powerful devices like the Nokia 1.

I also tried by setting mBufferSizeSelection to 4 or even 8, but there is no change at all.

Has anyone experienced something similar? Did I miss something?

Thanks for your help.

Solution

First thing is you shouldn't be doing your extraction and decoding inside the audio callback because this will block the audio callback until decoding has occurred which will be causing constant underruns.

Instead do the decoding after you set up your stream (after calling AudioStreamBuilder::openStream). That way your PCM data will be ready immediately when the audio callback occurs.

Secondly, what do you mean by "quite laggy"? There are a number of sources of lag in the signal path which include:

• Time taken for touch events to reach the app
• Time taken for the first audio callback to start if you're starting your stream from another thread
• Time taken for the vorbis decoding to occur
• Time taken for audio frames to arrive at the audio device
• Time taken for the rendered audio to reach the speaker or headphones (there can be DSP on the output path to improve acoustic qualities e.g. noise cancellation, bass boost etc)

I realise that this question is quite old so highly likely no longer relevant but would be interested to hear how you got on.

Answered By - donturner