Felix Nawothnig wrote:
Alex Villacís Lasso wrote:
wine-pthread: mixer.c:386: DSOUND_MixInBuffer: Assertion `adjusted_remainder >= 0' failed. wine: Unhandled exception (thread 000a), starting debugger... WineDbg starting on pid 0x8
I guess this is preluded by some "length not a multiple of block size" errors? I've been experiencing those errors with the same failed assertion in another game and came up with a similar patch but didn't submit since I think this just hides another bug as it should *not* happen that buf_mixpos becomes greater than buflen (and this >= above should probably be ==) at any time.
IMHO you should at least add an ERR to that branch.
--- wine-20050725-cvs/dlls/dsound/mixer.c 2005-06-21 04:43:29.000000000 -0500 +++ wine-20050725-cvs-patch/dlls/dsound/mixer.c 2005-08-01 02:16:42.000000000 -0500 @@ -491,6 +491,7 @@ if (dsb->leadin && (dsb->startpos <= dsb->buf_mixpos)) dsb->leadin = FALSE; /* HACK: see above */ }
else dsb->buf_mixpos = 0; /* %= dsb->buflen; */
And shouldn't it be "%= dsb->buflen;"? I'd think that this causes looping until new stuff is mixed in...
Felix
The patch I sent earlier was a tad incorrect: dsb->buf_mixpos == dsb->buflen is a valid state and should be allowed (miscorrection results in some samples being incorrectly looped). The attached patch will now only correct the situation when dsb->buf_mixpos > dsb->buflen, and will now display an ERR before doing so. In addition, the correction sets buf_mixpos back to buflen instead of wrapping or setting to zero, in order to be consistent with the dsb->buf_mixpos == dsb->buflen condition.
BTW, I think I located the source of the original assertion: a possible bug in DSOUND_MixerNorm() in dlls/dsound/mixer.c, which is returning one sample more than required to fill the buffer. I think the problem is the "different sample rate" scenario, but I was too tired to hunt for the bug last night.
Is the patent babble in DSOUND_MixerNorm() about PerfectPitch for real, or is it just a joke? It would be sad to remove functionality from Wine because of patent issues. Or it could be that I don't have a sense of humor...
Changelog: * Correction to earlier assertion patch to allow for buf_mixpos == buflen in non-looping case, fixes looping of one-off mixed samples introduced by previous patch.