Rogue OpenSL ES thread consumes CPU time when application is suspended

[simonmorris]

Hi there,
Many thanks for the useful library, it has worked an absolute treat for us.

I've encountered an issue with our application where I'm seeing a "rogue" thread created that continues to use CPU cycles when the application is suspended. I say rogue because it only shows up in HTOP, but not on ADM.

HTOP on android shows the suspect thread with a priority (PRI) of 4, and a nice value (NI) or -16, and on a Nexus 7 it quietly consumes between 4-9% of CPU, even though all the other threads in our suspended applications process are reporting 0% CPU usage.

I'm still investigating this issue, but right now the thread in question seems to be created a some point after alcOpenDevice and before alcCreateContext has completed. I strongly suspect it is slCreateEngine creating a worker thread.

So I'm wondering what the best practice is for handling audio when applications receive a suspend event? Currently our logic just pauses all streams/sounds and stop ticking the audio update loop. But perhaps should we be doing more to destroy/re-create the active context? Sounds like a headache though, I would prefer to dodge that.

I've looked around the net but not found any particular android guidelines for handling OpenSL ES audio when an application suspends, so any thoughts gratefully received.

Many thanks,
Simon

[simonmorris]

I found an issue. The callback thread for sound mixing continuously processes and queues up another buffer even when all sounds are paused. I worked around this by adding a function that puts the Open SL player object into a playing or stopped state depending on application lifecycle events. It's a bit hacky, but it got me out of a tight spot, since the mixer was consuming CPU cycles and battery power even when the device was on standby.

Here's the function source:

//SDM: The OpenSL implementation sets up the player to mix data continuously
// I added this function to give us a way to suspend or resume the player depending on application lifecycle.
ALCboolean alc_opensl_pause_player(ALCdevice *Device, ALCboolean state)
{
    osl_data *data = Device->ExtraData;
    SLPlayItf player;
    SLresult result;
    result = SLObjectItf_GetInterface(data->bufferQueueObject, SL_IID_PLAY, &player);
    PRINTERR(result, "bufferQueue->GetInterface");
    if(SL_RESULT_SUCCESS == result)
    {
        result = SLPlayItf_SetPlayState(player, (state == ALC_TRUE) ? SL_PLAYSTATE_PAUSED : SL_PLAYSTATE_PLAYING);
        PRINTERR(result, "player->SetPlayState");
    }
    if(SL_RESULT_SUCCESS != result)
    {
        if(data->bufferQueueObject != NULL)
            SLObjectItf_Destroy(data->bufferQueueObject);
        data->bufferQueueObject = NULL;
        free(data->buffer);
        data->buffer = NULL;
        data->bufferSize = 0;
        return ALC_FALSE;
    }
    return ALC_TRUE;
}

[simonmorris]

This is an excellent library by the way. Great work.

[martinfelis]

I ran into the same problem on my Android port of the LÖVE framework https://bitbucket.org/MartinFelis/love-android-sdl2. Using the latest OpenAL-Soft version 1.16.0 and using the new extension http://kcat.strangesoft.net/openal-extensions/SOFT_pause_device.txt solved the battery drain.