|
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.
|