You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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).
The text was updated successfully, but these errors were encountered:
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:
On 2014-04-30 22:09:31 +0000, Philipp Wiesemann wrote:
On 2014-05-24 20:54:43 +0000, Sylvain wrote:
On 2014-06-22 03:43:38 +0000, Sam Lantinga wrote:
On 2014-06-22 13:58:41 +0000, Gabriel Jacobo wrote:
On 2014-06-22 16:44:35 +0000, Sam Lantinga wrote:
On 2014-06-22 18:01:24 +0000, Sylvain wrote:
On 2014-06-22 18:06:16 +0000, Sam Lantinga wrote:
On 2014-06-22 21:40:11 +0000, Philipp Wiesemann wrote:
On 2014-06-24 22:54:02 +0000, wrote:
On 2014-06-25 07:25:44 +0000, Sam Lantinga wrote:
On 2014-08-05 14:36:56 +0000, Sylvain wrote:
On 2014-09-17 14:44:23 +0000, Gabriel Jacobo wrote:
On 2014-09-17 17:25:15 +0000, Sylvain wrote:
On 2014-09-17 17:25:38 +0000, Sylvain wrote:
On 2014-09-18 08:33:52 +0000, Philipp Wiesemann wrote:
On 2014-09-18 14:06:50 +0000, Gabriel Jacobo wrote:
On 2014-09-18 20:21:39 +0000, Philipp Wiesemann wrote:
The text was updated successfully, but these errors were encountered: