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