We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3412 - Infinite wait in SDL_CloseAudioDevice using winmm audio driver
Summary: Infinite wait in SDL_CloseAudioDevice using winmm audio driver
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 2.1
Hardware: x86_64 Windows 10
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-24 20:26 UTC by Kieran Yee
Modified: 2017-05-19 19:32 UTC (History)
2 users (show)

See Also:


Attachments
Short program to demonstrate the problem (830 bytes, text/x-csrc)
2016-08-24 20:26 UTC, Kieran Yee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kieran Yee 2016-08-24 20:26:24 UTC
Created attachment 2554 [details]
Short program to demonstrate the problem

Tested compiling with both Visual Studio and MinGW-w64, using SDL2 compiled from fresh (rev 10222) sources, as well as 2.0.4 sources. The sample program will reproduce the problem, but the gist of it is:

- Make sure SDL is using the winmm audio driver (export/set SDL_AUDIODRIVER=winmm)
- Open an audio device
- Immediately close that audio device

SDL_CloseAudioDevice will never return.

Only occurs when using the winmm audio driver. Adding a delay of any length between the two steps using SDL_Delay will "solve" the problem. I think this happens because of the audio device being placed in shutdown before the child thread gets to run? Will continue investigating.
Comment 1 Philipp Wiesemann 2016-08-25 20:48:00 UTC
SDL_CloseAudioDevice() waits for the audio thread to finish. This thread spins in WINMM_WaitDone() because the shutdown was requested before the playback was started.
Comment 2 Ryan C. Gordon 2017-05-19 19:32:05 UTC
This bug should be fixed when we stopped letting the audio targets be in charge of draining their own buffers on exit:

https://hg.libsdl.org/SDL/rev/d6427519ca66

(Please feel free to reopen this bug if this is still a problem though!)

--ryan.