|
3b191580
|
2022-06-27T17:19:39
|
|
Windows GDK Support (#5830)
* Added GDK
* Simplfied checks in SDL_config_wingdk.h
* Added testgdk sample
* Added GDK readme
* Fixed error in merge of SDL_windows.h
* Additional GDK fixes
* OpenWatcom should not export _SDL_GDKGetTaskQueue
* Formatting fixes
* Moved initialization code into SDL_GDKRunApp
|
|
0cca71a8
|
2022-05-18T22:12:05
|
|
Use SDLCALL for callbacks in public APIs
|
|
9e264b92
|
2022-04-18T09:20:47
|
|
Certain audio drivers, like the RME "Pro" Audio driver, have resampling quality issues when using WASAPI.
We'll use SDL's resampling algorithm so we have consistent quality between platforms and drivers.
Fixes https://github.com/libsdl-org/SDL/issues/5538
|
|
a70bb259
|
2022-01-20T13:16:03
|
|
drop handle parameter of OpenDevice
|
|
|
2eafe434
|
2022-01-20T12:18:59
|
|
cleanup/sync the main loop of *_OpenDevice functions to pick audio format
|
|
|
f91211eb
|
2022-01-19T14:51:42
|
|
cleanup WASAPI_PrepDevice
- reorganize the loop which checks for the right wave-format
- use the return value of UpdateAudioStream
- ensure SetError is called in SDL_NewAudioStream
|
|
|
1043dd8c
|
2022-01-19T12:58:04
|
|
adjust handling of iscapture
- drop iscapture parameter of OpenDevice
- use SDL_bool for iscapture
|
|
|
4a17612b
|
2022-01-17T12:04:32
|
|
get rid of BeginLoopIteration
|
|
|
0dda8a7f
|
2022-01-17T11:21:01
|
|
cleanup init functions of audio
- use SDL_bool if possible
- assume NULL/SDL_FALSE filled impl
- skip zfill of current_audio at the beginning of SDL_AudioInit (done before the init() calls)
|
|
|
120c76c8
|
2022-01-03T09:40:00
|
|
Updated copyright for 2022
|
|
2f0edc29
|
2021-12-04T09:23:19
|
|
IAudioClient::SetEventHandle Parameter eventHandle Should not be NULL
|
|
5c067906
|
2021-11-15T00:55:04
|
|
wasapi: AvSetMmThreadCharacteristicsW takes an LPCWSTR param, not LPWSTR
|
|
|
c2dd50a9
|
2021-11-12T08:28:02
|
|
Fixed whitespace
|
|
|
ed6eb07e
|
2021-08-12T01:40:50
|
|
SDL_wasapi.c: fixed build against older SDKs.
|
|
|
ac32c522
|
2021-08-10T18:11:09
|
|
Try using the built-in WASAPI audio rate conversion
Fixes https://github.com/libsdl-org/SDL/issues/4608
|
|
c72aef26
|
2021-05-01T23:56:23
|
|
Fixed microphone randomly stop working
WASAPI_WaitDevice is used for audio playback and capture, but needs to
behave slighty different.
For playback `GetCurrentPadding` returns the padding which is already
queued, so WaitDevice should return when buffer length falls below the
buffer threshold (`maxpadding`).
For capture `GetCurrentPadding` returns the available data which can be
read, so WaitDevice can return as soon as any data is available.
In the old implementation WaitDevice could suddenly hang. This is
because on many capture devices the buffer (`padding`) wasn't filled
fast enough to surpass `maxpadding`. But if at one point (due to unlucky
timing) more than maxpadding frames were available, WaitDevice would not
return anymore.
Issue #3234 is probably related to this.
|
|
4ef8674d
|
2021-07-27T14:18:44
|
|
Revert "wasapi: Open capture devices the way we used to."
This reverts commit 0d0fee7569803ddc41985bfc249418b02dd8cd97.
|
|
|
0d0fee75
|
2021-07-27T14:12:18
|
|
wasapi: Open capture devices the way we used to.
This should work around the regression in #3234, since it basically reverts
the problem change, but only for capture devices.
Fixes #3234.
|
|
|
db146e66
|
2021-05-25T10:34:04
|
|
Fixed warnings building with Visual Studio
|
|
9b7babf9
|
2021-03-27T00:47:54
|
|
wasapi: Remove assert added by 67e8522d
|
|
|
b98b5adc
|
2021-03-15T10:21:36
|
|
wasapi: Don't use the system's resampler.
|
|
|
391bb80b
|
2021-03-05T16:53:06
|
|
Replace duplicate functions and lstrlen/lstrcat with SDL string functions
|
|
|
67e8522d
|
2021-02-27T17:37:25
|
|
Add SDL_GetAudioDeviceSpec.
This API is supported by pipewire, pulseaudio, coreaudio, wasapi, and disk.
|
|
|
265a1cc9
|
2021-01-05T15:50:02
|
|
use WIN_StringToUTF8W instead of WIN_StringToUTF8 where needed (#2)
cf. bug #5435.
- SDL_wasapi_win32.c (GetWasapiDeviceName): pwszVal is WCHAR*
- windows/SDL_sysfilesystem.c (SDL_GetBasePath, SDL_GetPrefPath)
- windows/SDL_sysurl.c (SDL_SYS_OpenURL): wurl is WCHAR*
- SDL_windowssensor.c (ConnectSensor): bstr_name is WCHAR*
- windows/SDL_systhread.c (SDL_SYS_SetupThread): strw is WCHAR*
|
|
|
ed39f2f3
|
2021-01-04T01:23:50
|
|
SDL_wasapi_win32.c (WASAPI_PlatformThreadInit): use L instead of TEXT()
because AvSetMmThreadCharacteristicsW specifically accepts WCHAR* input
cf. bug #5435.
|
|
|
01a2f276
|
2021-01-04T01:23:50
|
|
consistently use TEXT() macro with LoadLibrary() and GetModuleHandle()
cf. bug #5435.
|
|
|
9130f7c3
|
2021-01-02T10:25:38
|
|
Updated copyright for 2021
|
|
|
cb361896
|
2020-12-09T07:16:22
|
|
Fixed bug 5235 - All internal sources should include SDL_assert.h
Ryan C. Gordon
We should really stick this in SDL_internal.h or something so it's always available.
|
|
|
68777406
|
2020-05-20T16:58:33
|
|
windows: Fix calls to CoCreateInstance() so last parameter is a LPVOID *.
|
|
|
fba081e4
|
2020-04-07T14:51:08
|
|
wasapi: Patched to compile on C89 systems, and use SDL_ceilf instead of ceilf.
|
|
|
4c2be472
|
2020-04-07T14:37:24
|
|
wasapi: Improve WASAPI audio backend latency (thanks, Anthony!).
Anthony Pesch's notes on his patch:
"Currently, the WASAPI backend creates a stream in shared mode and sets the
device's callback size to be half of the shared stream's total buffer size.
This works, but doesn't coordinate will with the actual hardware. The hardware
will raise an interrupt after every period which in turn will signal the
object being waited on inside of WaitDevice. From my empirical testing, the
callback size was often larger than the period size and not a multiple of it,
which resulted in poor latency when trying to time an application based on the
audio callback. The reason for this looked something like:
* The device's callback would be called and and the audio buffer was filled.
* WaitDevice would be called.
* The hardware would raise an interrupt after one period.
* WaitDevice would resume, see that a a full callback had not been played and
then wait again.
* The hardware would raise an interrupt after another period.
* WaitDevice would resume, see that a full callback + some extra amount had
been played and then it would again call our callback and this process would
repeat.
The effect of this is that the pacing between subsequent callbacks is poor -
sometimes it's called very quickly, sometimes it's called very late.
By matching the callback's size to the stream's period size, the pacing of
calls to the user callback is improved substantially. I didn't write an actual
test for this, but my use case for this was my Dreamcast emulator
(https://redream.io) which uses the audio callback to help drive the emulation
speed. Without this change and with the default shared stream buffer (which
has a period of ~10ms) I would get frame times that were between ~3-30
milliseconds; after this change I get frame times of ~11-22 milliseconds.
Note, this patch also has a change that removes passing a duration to the
Initialize call. It seems that the default duration used (when 0 is passed)
does typically match up with the duration returned by GetDevicePeriod, however
the Initialize docs say:
> To set the buffer to the minimum size required by the engine thread, the
> client should call Initialize with the hnsBufferDuration parameter set to 0.
> Following the Initialize call, the client can get the size of the resulting
> buffer by calling IAudioClient::GetBufferSize.
This change isn't strictly required, but I made it to hopefully rule out
another source of unexpected latency."
Fixes Bugzilla #4592.
|
|
|
b6afbe63
|
2020-04-07T09:38:57
|
|
Added SDL_log.h to SDL_internal.h so logging is available everywhere
|
|
27889d02
|
2020-03-03T12:31:41
|
|
winrt: Wait for EnumerationCompleted before leaving WASAPI_EnumerateEndpoints
|
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
|
8a37848d
|
2019-06-08T13:41:46
|
|
Fixed bug 4605 - WASAPI_WaitDevice hang
Matt Brocklehurst
We've noticed that if you are playing audio on Windows via the WASAPI interface and you unplug and reconnect the device a few times the program hangs.
We've debugged the problem down to
static void
WASAPI_WaitDevice(_THIS)
{
... snip ...
if (WaitForSingleObjectEx(this->hidden->event, INFINITE, FALSE) == WAIT_OBJECT_0) {
... snip ...
}
This WaitForSingleObjectEx does not havbe a time out defined, so it hangs there forever.
Our suggested fix we found was to include a time out of say 200mSec
We have done quite a bit of testing with this fix in place on various hardware configurations and it seems to have resolved the issue.
|
|
|
723d0143
|
2019-06-04T17:32:15
|
|
Fixed bug 4171 - SDL_GetQueuedAudioSize is broken with WASAPI
Cameron Gutman
I was trying to use SDL_GetQueuedAudioSize() to ensure my audio latency didn't get too high while streaming data in from the network. If I get more than N frames of audio queued, I know that the network is giving me more data than I can play and I need to drop some to keep latency low.
This doesn't work well on WASAPI out of the box, due to the addition of GetPendingBytes() to the amount of queued data. As a terrible hack, I loop 100 times calling SDL_Delay(10) and SDL_GetQueuedAudioSize() before I ever call SDL_QueueAudio() to get a "baseline" amount that I then subtract from SDL_GetQueuedAudioSize() later. However, because this value isn't actually a constant, this hack can cause SDL_GetQueuedAudioSize() - baselineSize to be < 0. This means I have no accurate way of determining how much data is actually queued in SDL's audio buffer queue.
The SDL_GetQueuedAudioSize() documentation says: "This is the number of bytes that have been queued for playback with SDL_QueueAudio(), but have not yet been sent to the hardware." Yet, SDL_GetQueuedAudioSize() returns > 0 value when SDL_QueueAudio() has never been called.
Based on that documentation, I believe the current behavior contradicts the documented behavior of this function and should be changed in line with Boris's patch.
I understand that exposing the IAudioClient::GetCurrentPadding() value is useful, but a solution there needs to take into account what of that data is silence inserted by SDL and what is actual data queued by the user with SDL_QueueAudio(). Until that happens, I think the best approach is to remove the GetPendingBytes() call until SDL is able to keep track of queued data to make sense of it. This would make SDL_GetQueuedAudioSize() possible to use accurately with WASAPI.
|
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
|
4a50a042
|
2018-10-21T22:40:17
|
|
wasapi/win32: Sort initial device lists by device GUID.
This makes an unchanged set of hardware always report devices in the same
order on each run.
|
|
|
7f9854b9
|
2018-09-25T01:45:12
|
|
WinRT: Wait until audio device activation is complete and PrepDevice during OpenAudio
|
|
|
99a0c0f0
|
2018-02-24T08:23:44
|
|
Fixed MinGW-w64 build
|
|
|
7e1fa0ce
|
2018-02-21T21:34:35
|
|
wasapi: fixed typo in an assert message.
|
|
|
c7e43665
|
2018-02-21T21:34:06
|
|
wasapi: let Windows do the resampling for us if possible.
|
|
40b27fd5
|
2018-02-12T17:00:00
|
|
revert the recent typecast assignment changes (see bug #4079)
also change the void* typedefs for the two vulkan function
pointers added in vulkan_internal.h into generic function
pointer typedefs.
|
|
|
90e72bf4
|
2018-01-30T18:08:34
|
|
Fixed ISO C99 compatibility
SDL now builds with gcc 7.2 with the following command line options:
-Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
|
|
|
48882401
|
2018-01-22T09:36:40
|
|
wasapi: Fixed some compiler warnings.
|
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
|
77bb49b7
|
2017-12-31T03:34:16
|
|
wasapi: Patched to compile on non-UWP WinRT builds.
|
|
|
ab4695f4
|
2017-12-13T14:35:55
|
|
wasapi: switched to event-driven interface.
This reduces latency and improves battery life.
|
|
|
351d6d47
|
2017-12-06T12:24:32
|
|
audio: Port WASAPI to WinRT, remove XAudio2 backend.
XAudio2 doesn't have capture support, so WASAPI was to replace it; the holdout
was WinRT, which still needed it as its primary audio target until the WASAPI
code code be made to work.
The support matrix now looks like:
WinXP: directsound by default, winmm as a fallback for buggy drivers.
Vista+: WASAPI (directsound and winmm as fallbacks for debugging).
WinRT: WASAPI
|
|
|
bcf0e071
|
2017-08-18T17:29:44
|
|
Added WASAPI audio target to autoconf build process
|
|
|
77ca0f27
|
2017-07-27T22:55:18
|
|
Fixed crash if the WASAPI audio device couldn't be recovered
|
|
|
4a734209
|
2017-07-27T22:52:19
|
|
Fixed infinite recursion if the WASAPI audio device couldn't be recovered
|
|
|
f033ce61
|
2017-07-27T02:41:58
|
|
Fixed typo in WASAPI shutdown code
|
|
|
e5918acf
|
2017-05-28T00:41:55
|
|
wasapi: properly report init failure if on pre-Vista version of Windows.
We really should change the Init interface to return 0 on success and -1 on
error, like everything else, to avoid this sort of confusion.
|
|
|
91e6054b
|
2017-05-19T12:40:55
|
|
wasapi: don't mark capture devices as failed for AUDCLNT_S_BUFFER_EMPTY.
Fixes Bugzilla #3633.
|
|
|
81ab6c98
|
2017-05-18T16:27:36
|
|
Patched to compile on Windows.
|
|
|
13b6d995
|
2017-05-18T15:46:06
|
|
wasapi: Replace tabs with strings in source code.
|
|
|
adabc384
|
2017-05-18T15:43:51
|
|
wasapi: Deal with AUDCLNT_S_BUFFER_EMPTY when flushing audio device.
|
|
|
028716e7
|
2017-03-30T16:33:47
|
|
wasapi: deal with default device changes, and more robust failure recovery.
|
|
|
c85c57a0
|
2017-03-29T14:23:39
|
|
wasapi: Handle lost audio device endpoints.
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.
|
|
|
6046fd4c
|
2017-02-14T03:03:27
|
|
wasapi: Initial WASAPI support, for Windows Vista and later.
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.
|