| Summary: | Play audio on Android while backgrounded? | ||
|---|---|---|---|
| Product: | SDL | Reporter: | superfury |
| Component: | audio | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | sylvain.becker |
| Version: | 2.0.12 | ||
| Hardware: | x86 | ||
| OS: | Windows 10 | ||
| Attachments: |
Changes to SDL Android using the new hint.
The new hint and implementation on the SDL 2.0.12 version. |
||
|
Description
superfury
2020-07-19 19:34:02 UTC
did you try to use SDL_HINT_ANDROID_BLOCK_ON_PAUSE not to block on pause ? SDL_HINT_ANDROID_BLOCK_ON_PAUSE is already set to 0, evidenced by the audio player not pausing when the app is minimized on Android. Audio rendering, however, still seems muted. ok, sorry! in: src/video/android/SDL_androidevents.c it calls ANDROIDAUDIO_PauseDevices(); openslES_PauseDevices(); when device is paused. only the event loop remain running. then it resumes: ANDROIDAUDIO_ResumeDevices(); openslES_ResumeDevices() @Sylvain I tried your approach, disabling both of those lines you've mentioned in comment #3. It seems to work. I'm thinking about something. Is this safe to use this way on all Android devices and/or apps? Or should it have a hint added to allow apps to enable this functionality (keep audio running in background)? I've implemented it like this: At the top of function Android_PumpEvents_NonBlocking(_THIS), below "backup_context = 0;": static int backup_audio = 0; Then before "backup_context = 0" within the isPaused check(after the context backup): if (SDL_GetHintBoolean(SDL_HINT_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO, SDL_TRUE)) //Stop audio when paused? { ANDROIDAUDIO_PauseDevices(); openslES_PauseDevices(); backup_audio = 1; //Audio is paused! } Finally, after SDL_SendWindowEvent(Android_Window, SDL_WINDOWEVENT_RESTORED, 0, 0); : if (backup_audio) //Audio is backed up? { ANDROIDAUDIO_ResumeDevices(); openslES_ResumeDevices(); backup_audio = 0; //Audio is resumed! } And in SDL_hints.h: /** * \brief A variable to control whether SDL will pause audio when not blocking the event loop itself when the app is paused. * * The variable can be set to the following values: * "0" - Non paused. * "1" - Paused. (default) * * The value should be set before SDL is initialized. */ #define SDL_HINT_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO "SDL_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO" Then, setting the hint to SDL_FALSE will cause audio to not be paused by SDL, allowing playing audio in the background? Created attachment 4469 [details]
Changes to SDL Android using the new hint.
For some reason, SDL on Android crashes with that patch? I was just thinking... Perhaps the issue is somewhere upstream from the SDL 2.0.12 tag until the current version on the default branch? Just confirmed: it's crashing on the current hg version. Created attachment 4470 [details]
The new hint and implementation on the SDL 2.0.12 version.
I've remade the patch for the SDL 2.0.12 commit.
This patch seems to run without issues, not crashing, both with the functionality enabled and disabled (and SDL_ANDROID_BLOCK_ON_PAUSE set to disabled of course).
So that 100% confirms that the current hg version of SDL has some issue somewhere with Android devices? It's crashing immediately when starting the app.
Can anyone put one of the two bugfixes into the hg tree if it's ok by QA standards? About the crash, perhaps commit 13946 is the cause? I see it changing various video initialization variables, while the definition of said variables stays unchanged? Just looked at the current source code. The commit 13946 is indeed the cause in later commits. It's changed back in current commits? Otherwise, I see no Android changes (besides logging). The crash seems to happen somewhere during SDL_Init. I changed a little bit the patch so there is less diff: https://hg.libsdl.org/SDL/rev/064eaa6b911d I see no crash with latest head. Maybe clean + recompile. Don't forget to update the java side, if needed. (changeset 13946 is https://hg.libsdl.org/SDL/rev/5acc27d3d654 and doesn't look strange) Just rebuilt with updating the SDL Java files. That seems to have fixed the crash! :D The fix is now implemented in hg and fixed. Thanks for the help! ok great thanks ! |