DSOUND: prevent assertion in mixer.c

Alex Villací­s Lasso a_villacis at palosanto.com
Wed Aug 3 11:36:19 CDT 2005

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 

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 

* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-dsound-mixer-DSOUND_MixInBuffer_2.patch
Type: text/x-patch
Size: 571 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050803/48021e7e/wine-dsound-mixer-DSOUND_MixInBuffer_2.bin

More information about the wine-devel mailing list