Sylvain Becker

btw there is SDL_HINT_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO so that it can still play audio in background (it simply doesn't pause the audio in bg). Blocking on pause seems to me a good default...

I think this may be confusing and people are going start reporting issues and/or event not seeing their issues. but we can try and that would be ? ```diff src/video/android/SDL_androidvideo.c...

not from me, not sure what SDL3 behavior change is expected here ? I haven't re-read this, but from me last message it could be simply changing the default values...

Not really sure with want this. Most app usually doesn't play music in background nor try to render in background or eat 100% in bg. Currently, it's seamlessly working when...

Just adding it ``` impl->OnlyHasDefaultOutputDevice = SDL_FALSE; impl->OnlyHasDefaultCaptureDevice = SDL_FALSE; impl->AllowsArbitraryDeviceNames = SDL_TRUE; ```

devname is sent to opensles. for capture, it seems there is openslES_CreatePCMRecorder that should be modified to fill: ``` 255 loc_dev.locatorType = SL_DATALOCATOR_IODEVICE; 256 loc_dev.deviceType = SL_IODEVICE_AUDIOINPUT; 257 loc_dev.deviceID =...

yes, maybe not a bug. just questioning ... also, we notice it happened using: ` if (SDL_CreateWindowAndRenderer(WIDTH, HEIGHT, 0, &g_window, &g_renderer) < 0) {` it had : ``` SDL_Surface *scr...

sounds like a compiler issue ? try to comment out function implement in SDL_RLEaccel.c to find the culprit

instead of fully using SDL_LEAN_AND_MEAN, you simply #define SDL_HAVE_RLE 0 and there will be no RLE support

It doesn't seem so obvious. the signed by 8 division is probably optimized by the compiler. and using twice pixel_copy_increment4 would allow more prefetch in fact, I just quickly tested...