Hi Hiroki,
This change looks good to me.
I wrote some tests to confirm that Windows does not get stuck in this situation. I attached the diff if you are curious, but I think it is OK to skip tests for this since it depends on timing and internal Wine behavior.
However, I think this patch creates some new dead code. Since a render buffer now cannot ever be in the STATE_STOPPING state, there is no need to handle that state in other places, like IDirectSoundBufferImpl_Play and DSOUND_MixToPrimary.
Thanks, Andrew
On Thu, Jun 03, 2021 at 03:12:23PM +0900, Hiroki Awata wrote:
Some games may not receive the DSBPN_OFFSETSTOP event and get stuck if CloseHandle is called immediately after IDirectSoundBuffer::Stop. To solve this problem, IDirectSoundBuffer::Stop will immediately notify the DSBPN_OFFSETSTOP event.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41292 Signed-off-by: Hiroki Awata castaneai@by.black
dlls/dsound/buffer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/dlls/dsound/buffer.c b/dlls/dsound/buffer.c index fafa6fc6015..8cbcd8f9fc5 100644 --- a/dlls/dsound/buffer.c +++ b/dlls/dsound/buffer.c @@ -317,9 +317,7 @@ static HRESULT WINAPI IDirectSoundBufferImpl_Stop(IDirectSoundBuffer8 *iface)
AcquireSRWLockExclusive(&This->lock);
- if (This->state == STATE_PLAYING)
This->state = STATE_STOPPING;- else if (This->state == STATE_STARTING)
- if (This->state == STATE_PLAYING || This->state == STATE_STARTING) { This->state = STATE_STOPPED; DSOUND_CheckEvent(This, 0, 0);
-- 2.27.0