kmx git

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

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

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.

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.

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