kmx git

Commit	Date	Message
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.
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
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
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
c7e43665	2018-02-21T21:34:06	wasapi: let Windows do the resampling for us if possible.
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.

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.

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

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

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

c7e43665

2018-02-21T21:34:06

wasapi: let Windows do the resampling for us if possible.

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/SDL_wasapi.c

src/audio/wasapi/SDL_wasapi.c

Log