Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Music does not pause when process backgrounded on Android #1429

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Music does not pause when process backgrounded on Android #1429

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels

Comments

@SDLBugzilla
Copy link
Collaborator

@SDLBugzilla SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.3
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2014-04-07 04:34:23 +0000, Brian E Lavender wrote:

I am using SDL2_mixer on my SDL2 android game. Problem is that when my user hits the home button or does something to background my game, the music keeps playing. The game suspends, but not the music. I realize this may be desired behavior in certain cases, but not this one.

How can I have SDL pause the music when my Android app is not in the foreground?

Is there some way to register the following instruction when the app is backgrounded?
Mix_PauseMusic();

On IRC someone suggested that it actually might be a bug.

brian

On 2014-04-30 22:09:31 +0000, Philipp Wiesemann wrote:

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.

On 2014-05-24 20:54:43 +0000, Sylvain wrote:

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 ...

On 2014-06-22 03:43:38 +0000, Sam Lantinga wrote:

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?

On 2014-06-22 13:58:41 +0000, Gabriel Jacobo wrote:

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.

On 2014-06-22 16:44:35 +0000, Sam Lantinga wrote:

Yeah, let's do this.

On 2014-06-22 18:01:24 +0000, Sylvain wrote:

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,

On 2014-06-22 18:06:16 +0000, Sam Lantinga wrote:

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.

On 2014-06-22 21:40:11 +0000, Philipp Wiesemann wrote:

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

On 2014-06-24 22:54:02 +0000, wrote:

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.

On 2014-06-25 07:25:44 +0000, Sam Lantinga wrote:

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.

On 2014-08-05 14:36:56 +0000, Sylvain wrote:

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.

On 2014-09-17 14:44:23 +0000, Gabriel Jacobo wrote:

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.

On 2014-09-17 17:25:15 +0000, Sylvain wrote:

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

On 2014-09-17 17:25:38 +0000, Sylvain wrote:

Thanks :) !

On 2014-09-18 08:33:52 +0000, Philipp Wiesemann wrote:

(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.

On 2014-09-18 14:06:50 +0000, Gabriel Jacobo wrote:

(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

On 2014-09-18 20:21:39 +0000, Philipp Wiesemann wrote:

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant