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);
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
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=91928
Your paranoid android.
=== debiant2 (32 bit report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit Arabic:Morocco report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit French report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit Hebrew:Israel report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit Hindi:India report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit Japanese:Japan report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit Chinese:China report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (32 bit WoW report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258
=== debiant2 (64 bit WoW report) ===
dsound: dsound.c:1089: Test failed: expected 0. got 258 dsound.c:1089: Test failed: expected 0. got 258