kmx git

Commit	Date	Message
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.

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.

kc3-lang/SDL/src/audio/wasapi

src/audio/wasapi

Log