[PATCH v2] dsound: Notify DSBPN_OFFSETSTOP earlier.

[Andrew Eikum]

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 at 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_207087.diff
Type: text/x-diff
Size: 4473 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210604/7603844d/attachment.diff>