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 the3dfxdude@gmail.com wrote:
On 10/31/05, Davin McCall davmac@davmac.org 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