The message sent upon the window being activated or deactivated, to trigger
the call to SDL_SetKeyboardFocus was missing a mandatory parameter. So
keyboard focus was never properly set.
Fixes Bugzilla #3658.
We don't fill buffers just to throw them away during shutdown now, we let the
AudioQueue free its own buffers during disposal (which fixes possible warnings
getting printed to stderr by CoreAudio), and we stop the queue after running
any queued audio during shutdown, which prevents dropping the end of the
audio playback if you opened the device with an enormous sample buffer.
Fixes Bugzilla #3555.
We need more than two buffers to flip between if they are small, or CoreAudio
won't make any sound; apparently it needs X milliseconds of audio queued when
it needs to play more or it drops any queued buffers. We are currently
guessing 50 milliseconds as a minimum, but there's probably a more proper
way to get the minimum time period from the system.
Fixes Bugzilla #3656.
Fixes Bugzilla #3448.
"Starting with Android API 13, another configuration change must be declared
to be handled by the app if it is desired to not let the system handle
rotation itself:
https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChange
This will have effect if either a developer or SDL per default will set target
API > 12. Currently it is set to 12, but this might change in the future, like
when applying this patch: https://bugzilla.libsdl.org/show_bug.cgi?id=3445
The effect of not having this change applied is that the SDL app is destroyed
upon rotation. Even when the manifest has an additional entry to e.g. always
stay in landscape mode, the onDestroy() call will happen on devices that are
portrait per default, when switching off screen due to power save. The device
will then (at least try to) rotate into portrait to show the portrait screen
lock after resume.
I believe it is safe to apply this patch even with target API still set to 12,
the additional parameter is simply ignored."
If an Emscripten app is in relative mouse mode and the user presses Escape
(or whatever is appropriate), then the pointer lock is broken by the browser.
This keeps track of those losses, and next time the user presses a mouse
button down on the canvas, if the app is still meant to be in relative mouse
mode, we will attempt to regrab the pointer.
This makes it much more seamless for things like first-person shooters, and
the app doesn't need any manual intervention.
Fixes Bugzilla #3562.
From Sylvain:
"With an android landscape application, if you quickly lock, then unlock your
device, you can see sometimes a quick glitch: screen badly draws in portrait,
then it correctly displays in landscape.
Not talking of a smooth rotation, it's a drawing glitch. And you need to have
a plain lock screen, with no model nor passphrase.
I think it happens because the call to "nativeResume()" occurs sometimes too
early.
It should be done once you have *all* those three things (in any sequence):
- onWindowsFocusChanged() set to true
- onResume() called
- a valid call to onSurfaceChanged()
Currently, this is not the case: you don't need to have onResume() called.
Just need to have isPaused, (eg onPaused()).
So "isPaused" should be renamed as "isResumedCalled".
But you also need some kind of isPaused state to make sure to don't call
nativePause() twice (and deadlocks...).
There are also redundant checks to "mHasFocus" and some creation of the
initialisation thread code from onSurfaceChanged() that could me moved.
So here's this patch:
- add some states, so we have cleaner transitions.
- make sure "onResume()" is called.
- some clean up
- it also goes faster in pause state (focus changed, onPause, without requiring isSurfaceReady which does seems to be needed).
Tested on a few devices and it removes the glitch.
But I haven't tested when the activity goes back to "init" state."
"Using an application in portrait orientation, turning off the device would
dispatch SDL_APP_WILLENTERBACKGROUND, then SDL_APP_DIDENTERBACKGROUND then
lock the screen.
However, rotating the application the application to landscape, then turning
off the device would incorrectly dispatch SDL_APP_WILLENTERBACKGROUND,
SDL_APP_WILLENTERBACKGROUND, SDL_APP_WILLENTERFOREGROUND and then
SDL_APP_DIDENTERFOREGROUND before locking the screen. You can imagine how
this created trouble :)
It appears this occurs because (on this application) turning off a device
when in landscape is triggering a resize. The resize logic in SDLActivity
triggers a resume.
This patch has resolved the issue on my device:
It prevents the dispatch of (improper) FOREGROUND events when locking
the device, but we get still events when the device is turned back on
and unlocked."
This gracefully recovers when a device format is changed, and will switch
to the new default device if the current one is unplugged, etc.
This does not handle when a new default device is added; it only notices
if the current default goes away. That will be fixed by implementing the
stubbed-out MMNotificationClient_OnDefaultDeviceChanged() function.
These don't have to be power-of-2 sizes anymore because of SDL_AudioStream,
and the new resampler, but also, many platforms don't give you power-of-2 DMA
buffer in the first place!
We will throw away the data anyhow, but some apps depend on the callback
firing to make progress; testmultiaudio.c, if nothing else, is an example
of this.
Capture also will now fire the callback in these conditions, offering nothing
but silence.
Apps can check SDL_GetAudioDeviceStatus() or listen for the
SDL_AUDIODEVICEREMOVED event if they want to gracefully deal with
an opened audio device that has been unexpectedly lost.
This is just enough to get you through a file that just used the extended
header for float or int data. It doesn't handle all the other things that
you expect from this header, like 24-bit samples inside a 32-bit container
or speaker masks.
This should remain binary compatible with Windows XP, as we dynamically
load anything we need and fall back to DirectSound/WinMM/XAudio2 if not
available.
Like other C runtimes, it should probably produce the string "(null)".
This bug probably only affected Windows, as most platforms use their standard
C runtime's snprintf().
This is a bleeding edge API, added to Windows 10 Anniversary Edition (build
1607, specifically).
https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx
Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc,
so we still need to also use the RaiseException hack. But presumably tools
will use this API as a more robust and universal way to get thread names
sooner or later, so we'll start broadcasting to it now.
This defaults to the internal SDL resampler, since that's the likely default
without a system-wide install of libsamplerate, but those that need more can
tweak this.
This currently favors libsamplerate over the fast path (quality over speed),
but I'm not sure that's the correct approach, as there may be surprising
changes in performance metrics depending on what packages are available on
a user's system. That being said, currently, the only thing with access to
SDL_AudioStream is an SDL audio device's thread, and it might be mostly idle
otherwise, so maybe this is generally good.
Turns out that iterating from 0 to channels-1 was a serious performance hit!
These cases now tend to match or beat the original audio resampler's speed!
This allows us to avoid an extra copy, allocate less memory and reduce cache
pressure. On the downside: we have to do a lot of tapdancing to resample the
buffer in reverse when the output is growing.
It's expensive and (hopefully) unnecessary. If this becomes an overflow
problem, we could multiply both values by 0.5f before adding them, but let's
see if we can get by without the extra multiplication first.
We never seem to overflow the source buffer now; this might have been a
leftover from a bug that was covered by Vitaly's fixes?
Removing this conditional makes the resampler 10-20% faster. Left an
assert in there for debug builds, in case this still happens.
Removed some needless things ("len / sizeof (Uint8)"), and made sure the
int32 -> float code uses doubles to avoid working with large integer values
in a 32-bit float.
Ryan C. Gordon