src/audio/wasapi


Log

Author Commit Date CI Message
chalonverse 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
Cameron Cawley 0cca71a8 2022-05-18T22:12:05 Use SDLCALL for callbacks in public APIs
Sam Lantinga 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
pionere a70bb259 2022-01-20T13:16:03 drop handle parameter of OpenDevice
pionere 2eafe434 2022-01-20T12:18:59 cleanup/sync the main loop of *_OpenDevice functions to pick audio format
pionere 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
pionere 1043dd8c 2022-01-19T12:58:04 adjust handling of iscapture - drop iscapture parameter of OpenDevice - use SDL_bool for iscapture
pionere 4a17612b 2022-01-17T12:04:32 get rid of BeginLoopIteration
pionere 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)
Sam Lantinga 120c76c8 2022-01-03T09:40:00 Updated copyright for 2022
ALittleDruid 2f0edc29 2021-12-04T09:23:19 IAudioClient::SetEventHandle Parameter eventHandle Should not be NULL
Ozkan Sezer 5c067906 2021-11-15T00:55:04 wasapi: AvSetMmThreadCharacteristicsW takes an LPCWSTR param, not LPWSTR
Sam Lantinga c2dd50a9 2021-11-12T08:28:02 Fixed whitespace
Ozkan Sezer ed6eb07e 2021-08-12T01:40:50 SDL_wasapi.c: fixed build against older SDKs.
Sam Lantinga ac32c522 2021-08-10T18:11:09 Try using the built-in WASAPI audio rate conversion Fixes https://github.com/libsdl-org/SDL/issues/4608
Splamy 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.
Ryan C. Gordon 4ef8674d 2021-07-27T14:18:44 Revert "wasapi: Open capture devices the way we used to." This reverts commit 0d0fee7569803ddc41985bfc249418b02dd8cd97.
Ryan C. Gordon 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.
Sam Lantinga db146e66 2021-05-25T10:34:04 Fixed warnings building with Visual Studio
Ethan Lee 9b7babf9 2021-03-27T00:47:54 wasapi: Remove assert added by 67e8522d
Ryan C. Gordon b98b5adc 2021-03-15T10:21:36 wasapi: Don't use the system's resampler.
Cameron Cawley 391bb80b 2021-03-05T16:53:06 Replace duplicate functions and lstrlen/lstrcat with SDL string functions
Ethan Lee 67e8522d 2021-02-27T17:37:25 Add SDL_GetAudioDeviceSpec. This API is supported by pipewire, pulseaudio, coreaudio, wasapi, and disk.
Ozkan Sezer 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*
Ozkan Sezer 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.
Ozkan Sezer 01a2f276 2021-01-04T01:23:50 consistently use TEXT() macro with LoadLibrary() and GetModuleHandle() cf. bug #5435.
Sam Lantinga 9130f7c3 2021-01-02T10:25:38 Updated copyright for 2021
Sam Lantinga 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.
Ryan C. Gordon 68777406 2020-05-20T16:58:33 windows: Fix calls to CoCreateInstance() so last parameter is a LPVOID *.
Ryan C. Gordon fba081e4 2020-04-07T14:51:08 wasapi: Patched to compile on C89 systems, and use SDL_ceilf instead of ceilf.
Ryan C. Gordon 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.
Sam Lantinga b6afbe63 2020-04-07T09:38:57 Added SDL_log.h to SDL_internal.h so logging is available everywhere
Ethan Lee 27889d02 2020-03-03T12:31:41 winrt: Wait for EnumerationCompleted before leaving WASAPI_EnumerateEndpoints
Sam Lantinga a8780c6a 2020-01-16T20:49:25 Updated copyright date for 2020
Sam Lantinga 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.
Sam Lantinga 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.
Sam Lantinga 5e13087b 2019-01-04T22:01:14 Updated copyright for 2019
Ryan C. Gordon 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.
Ethan Lee 7f9854b9 2018-09-25T01:45:12 WinRT: Wait until audio device activation is complete and PrepDevice during OpenAudio
Sam Lantinga 99a0c0f0 2018-02-24T08:23:44 Fixed MinGW-w64 build
Ryan C. Gordon 7e1fa0ce 2018-02-21T21:34:35 wasapi: fixed typo in an assert message.
Ryan C. Gordon c7e43665 2018-02-21T21:34:06 wasapi: let Windows do the resampling for us if possible.
sezero 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.
Sam Lantinga 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
Ryan C. Gordon 48882401 2018-01-22T09:36:40 wasapi: Fixed some compiler warnings.
Sam Lantinga e3cc5b2c 2018-01-03T10:03:25 Updated copyright for 2018
Ryan C. Gordon 77bb49b7 2017-12-31T03:34:16 wasapi: Patched to compile on non-UWP WinRT builds.
Ryan C. Gordon ab4695f4 2017-12-13T14:35:55 wasapi: switched to event-driven interface. This reduces latency and improves battery life.
Ryan C. Gordon 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
Sam Lantinga bcf0e071 2017-08-18T17:29:44 Added WASAPI audio target to autoconf build process
Sam Lantinga 77ca0f27 2017-07-27T22:55:18 Fixed crash if the WASAPI audio device couldn't be recovered
Sam Lantinga 4a734209 2017-07-27T22:52:19 Fixed infinite recursion if the WASAPI audio device couldn't be recovered
Sam Lantinga f033ce61 2017-07-27T02:41:58 Fixed typo in WASAPI shutdown code
Ryan C. Gordon 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.
Ryan C. Gordon 91e6054b 2017-05-19T12:40:55 wasapi: don't mark capture devices as failed for AUDCLNT_S_BUFFER_EMPTY. Fixes Bugzilla #3633.
Ryan C. Gordon 81ab6c98 2017-05-18T16:27:36 Patched to compile on Windows.
Ryan C. Gordon 13b6d995 2017-05-18T15:46:06 wasapi: Replace tabs with strings in source code.
Ryan C. Gordon adabc384 2017-05-18T15:43:51 wasapi: Deal with AUDCLNT_S_BUFFER_EMPTY when flushing audio device.
Ryan C. Gordon 028716e7 2017-03-30T16:33:47 wasapi: deal with default device changes, and more robust failure recovery.
Ryan C. Gordon 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.
Ryan C. Gordon 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.