We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

This happens because SDL's audio callback thread is not automatically paused if the application's main thread is paused.

Therefore this would be a bug in SDL and not SDL_mixer. It should also happen with SDL's own audio functionality (on which SDL_mixer is based).

A fix would break existing applications which already rely on this behavior. Although this behavior would only be useful for looping the same music or sounds.

Brian, maybe calling SDL_LockAudio() when going to background, and SDL_UnlockAudio() would do the trick of pausing the audio thread. 

Don't know if this can have side effects ...

It seems reasonable that the game sounds pauses when the application itself pauses.

Gabriel, do you know if there is any application that relies on the current behavior?

This is very easy to do from the application side, you pause/resume music on SDL_APP_WILLENTERBACKGROUND/SDL_APP_WILLENTERFOREGROUND

I don't know if pausing the SDL audio thread works at all for this...and we can't pause SDL_mixer from SDL without making the assumption that SDL_mixer will be present.

If pausing the audio thread works for pausing and resuming I'd say let's go for it. If there are applications that require playing sounds in the background, we can provide a hint for them.

Yeah, let's do this.

Hi, 

Even if the user call :
MixPause(-1) and SDL_PauseAudio(1) in SDL_WILL_ENTER_BACKGROUND

(and MixResume(-1) and SDL_PauseAudio(0) MixResume in SDL_WILL_ENTER_FOREGROUND )


The audio thread (SDL_audio.c) still run and wake up at the rate of 50Hz on Android! (but of course, there is no audio).
It looks terrible to have an app which is in background for days :) but still waked up at this rate !

The only way I have found to really *block* the audio-thread is to call SDL_LockAudio() in SDL_WILL_ENTER_BACKGROUND : the semaphore is taken and the thread is blocked. (hopefully the thread is never rescheduled).

and SDL_UnlockAudio() in SDL_WILL_ENTER_FOREGROUND.

(Also, an extra calls to SDL_UnlockAudio() at the end/destruction of my app (before Mixer_CloseAudio). In case the app is asked to terminate (SDL_APP_TERMINATE) while the app is already in background (AudioLock already taken) !).


SDL_Lock/UnlockAudio is in SDL, not SDL_mixer. It might be SDL_mixer-agnostic.

Maybe that SDL_Lock/UnlockAudio shoud be called in the *generic* layer. I mean this does not look specific to Android and could be applied for each platform that goes to background/foreground! (... well, maybe not for Desktops..)

Cheers,

It definitely seems like the SDL Android code should stop the audio thread when the application goes into the background, unless there's a hint to prevent it.

This would prevent the power drain that you're talking about, Sylvain.

Maybe SDL_ANDROID_BLOCK_ON_PAUSE could include the audio thread. Blocking is default. No additional hint would be needed then.

Just here to second this: The behavior I expect is that if SDL_ANDROID_BLOCK_ON_PAUSE is set, the audio thread will also pause when the app is backgrounded.

SDL_ANDROID_BLOCK_ON_PAUSE behavior shouldn't be directly tied to stopping the audio thread. It's designed to be an alternative way to handle Android activity life cycle and I expect the activity behavior to be resolved one way or the other by SDL 2.1.

We should definitely have a different hint, and it should probably affect all platforms.

An android user reports me this same bug and also gives me some interesting debugging commands. 
Basically, when the screen is off, Audio is still running and consuming battery.

>
> First, I connected the tablet to the computer when the screen was off.
> 
> % adb shell dumpsys power | grep -i wake
> 
> ...
> PARTIAL_WAKE_LOCK      'AudioMix' (uid=1013, pid=137, ws=WorkSource{10143})
> ...
> 
> The ws=WorkSource{10143} seems to say that the AudioMix is required by app with uid = 10143. 
> As far as I know, app uid = 10000 + app_number. 
> So I looked which app has assigned app_number = 143 on my tablet:
> 
> % adb shell ps | grep 143
> u0_a143   2707  135   624616 56824 ffffffff 00000000 S ****This.Is.My.Application****
> 


This is an application that I have not updated for a while. It just do normal stuff before going to background.

So I asked him to do the same procedure with another application which has a call to SDL_LockAudio() before entering background.

On this more recent application, the PARTIAL_WAKE_LOCK is not present.

Let me know if this works for you http://hg.libsdl.org/SDL/rev/aa99e029b12e

I tested with testmultiaudio.c and it seems to work nicely.

To me it works, no PARTIAL_WAKE_LOCK and CPU is reduced!

Thanks :) !

(In reply to Gabriel Jacobo from comment #12)
> Let me know if this works for you http://hg.libsdl.org/SDL/rev/aa99e029b12e
> 
> I tested with testmultiaudio.c and it seems to work nicely.

If the audio device was paused before the application went into the background it will not be paused after returning to the foreground again.

(In reply to Philipp Wiesemann from comment #15)

> If the audio device was paused before the application went into the
> background it will not be paused after returning to the foreground again.

You are correct! Better fix committed here: http://hg.libsdl.org/SDL/rev/e9b6e9f4a10e

Thank you for fixing this.

Unrelated to the default blocking:

Currently the audio thread is blocked if SDL_ANDROID_BLOCK_ON_PAUSE is 0. I think this is inconsistent because the main thread is still active. The application is therefore just in a "minimized" state (like on desktop platforms). In my opinion the audio thread should not be blocked here so that the application can decide if audio output should be stopped or not (like it has to handle stopping to draw itself).