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