DSOUND: prevent assertion in mixer.c
felix.nawothnig at t-online.de
Tue Aug 2 15:49:21 CDT 2005
Alex Villacís Lasso wrote:
>> 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.
> The "length not a multiple of block size" errors you mention is what
> happens *instead* of the failed assertion when this patch is applied.
That's strange. I thought the failed assertion was caused by mixpos
being increased by the fragment size rounded up to the next block size
multiple... (the blocksize was 2 so mixpos was always buflen+1 when the
> Since the error of "length not a multiple of block size" is nonfatal,
Yes it is fatal. Errors mean that something which should not have
happened did happen - and we're not talking about something the API is
supposed to handle... there is wrong code in Wine, internal states might
have gone corrupted and you can no-longer be sure that Wine is working
The difference to an assert() is that it's probably possible to repair
the corrupted state but there is no guarantee for that since the error
might be caused by completly unrelated code.
And this is exactly what we you do in your code - you dunno the reason
why mixpos became greater than buflen but you know how to handle it,
that's why you should put an ERR there.
> unlike the assertion, I submitted the patch as it is. I will need to
> read more of both DirectSound and the source code in order to understand
> the implications of the non-multiple error, since there is another game
> from the same source (LittleWitch/FloatingFrameDirector) that displays
> the same non-multiple errors without triggering the assertion. What kind
In the game I tested the assertion failure was not really reproducable,
sometimes I played through the whole game (a demo) without problems - it
also seems to be timing related...
> of setup or error needs to happen in an DirectSound application in order
> to trigger this non-multiple warning?
Well, fragments of the wrong size are mixed in... but I dunno where they
come from since I dunno anything about the DSound API. :-)
>> And shouldn't it be "%= dsb->buflen;"? I'd think that this causes
>> looping until new stuff is mixed in...
> I tested with the particular game, and it made no difference. The
> comment is there so it is evident that I tested both.
Maybe new samples are immediatly mixed in?
More information about the wine-devel