No - that's an unrelated problem. The DSOUND_PhaseCancel method is being requested to cancel a length which isn't an integer number of frames.
Probably it is being called from somewhere which isn't doing correct length translation of secondary to primary buffer (ie primary_length = secondary_length / secondary_blocksize * primary_blocksize. The secondary blocksize may be smaller if it is a mono buffer, for instance. That calculation is oversimplified also, because sample rates between the buffers may vary and this needs to be taken into account. I plan to keep looking at DSound issues but I like to do these things progressively (i.e. get a few patches submitted and accepted, then do some more) - otherwise the change ends up being huge, and to break it up is a lot of work. BTW, thanks for the note re patch acceptance. I had noticed some patches which had been sent in after mine had been accepted, so I guess I got worried - but you're right, it's too soon (though it is in fact Tuesday in my time zone :-)) Davin On Mon, 31 Oct 2005 18:07:08 -0700 Jesse Allen <[EMAIL PROTECTED]> wrote: > On 10/31/05, Davin McCall <[EMAIL PROTECTED]> wrote: > > > > This is one is probably the most trivial fix and is largely unrelated to > > the other fixes. But if you look at the code for a while as I have you can > > see that it's obviously correct - the existing implementation of > > PhaseCancel inverts the original waveform; with this patch it doesn't. > > > > > BTW, do you think this error with D2 is related to this bug you found? > This is from wine plus your other patch. See previous message. > > err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len > = 3026, block size = 4 > > Thanks, > Jesse
