DSOUND: prevent assertion in mixer.c

[Felix Nawothnig]

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 
assertion failed)

> 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 
correctly.

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?

Felix