On Mon, Sep 13, 2021 at 10:33:38AM -0500, Andrew Eikum wrote:
This is looking pretty good. I'm going to run it through my set of dsound test applications
Bad news, it causes a crash in the Darwinia 2 demo for me :(
$ md5sum darwinia-demo2.exe 3f5d3fd40db15dd1a7e51891f385c57f darwinia-demo2.exe
https://www.moddb.com/games/darwinia/downloads/darwinia-windows-demo
Andrew
On Fri, Sep 10, 2021 at 06:36:23PM +0300, Eduard Permyakov wrote:
diff --git a/dlls/dsound/buffer.c b/dlls/dsound/buffer.c index dc3b54906ce..63468732e1d 100644 --- a/dlls/dsound/buffer.c +++ b/dlls/dsound/buffer.c @@ -101,6 +101,24 @@ static int __cdecl notify_compar(const void *l, const void *r) return 1; }
+static void commit_next_chunk(IDirectSoundBufferImpl *dsb) +{
- void *dstbuff = dsb->committedbuff, *srcbuff = dsb->buffer->memory;
- DWORD srcoff = dsb->sec_mixpos, srcsize = dsb->buflen, cpysize = dsb->writelead;
- if(cpysize > srcsize - srcoff) {
DWORD overflow = cpysize - (srcsize - srcoff);memcpy(dstbuff, (BYTE*)srcbuff + srcoff, srcsize - srcoff);memcpy((BYTE*)dstbuff + (srcsize - srcoff), srcbuff, overflow);- }else{
memcpy(dstbuff, (BYTE*)srcbuff + srcoff, cpysize);- }
- dsb->use_committed = TRUE;
- dsb->committed_mixpos = 0;
Is it right to always reset this to zero? Is it possible an app could write to the committed chunk while committed_mixpos is non-zero, and so reset committed_mixpos when it shouldn't be?
@@ -153,7 +153,12 @@ struct IDirectSoundBufferImpl LONG64 freqAccNum; /* used for mixing */ DWORD sec_mixpos;
- /* Holds a copy of the next 'writelead' bytes, to be used for mixing. This makes it
* so that these bytes get played once even if this region of the buffer gets overwritten,* which is more in-line with native DirectSound behavior. */- BOOL use_committed;
- LPVOID committedbuff;
- DWORD committed_mixpos;
I think use_committed (and committed_mixpos?) should be initialized in Duplicate. What about SetCurrentPosition?
Andrew