jwhite at codeweavers.com
Mon Feb 28 11:23:14 CST 2005
Ove Kaaven wrote:
> tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White:
>>Case 1: In the first case, in DSOUND_MixOne, we compute
>>a 'probably_valid_to' based on the 'write_pos', which seems quite
>>wrong; I believe the logic should be testing whether or not
>>there is sufficient data in the mixing buffer, not whether or
>>not there is sufficient room in the buffer overall.
> The probably_valid_to check is for whether there's likely to be
> sufficient data in the *source* streaming buffer to warrant filling the
> destination buffer. If the app has only half-filled the streaming
> buffer, then it's a better idea to only mix what we know it put there,
> and mix the rest of the buffer only after the app has written more stuff
> to the buffer, rather than mix everything we can, including invalid
> data, then having to backtrack and do a full mix reset when the app
> overwrites the invalid data with valid data. The existing code should be
Whoops; I think I see the source of the confusion. I meant to say
that the computation of 'probably_valid_left' was incorrect
(which is what my patch addressed); the use and computation of
'probably_valid_to' is correct afaict.
In fact, I believe my code more properly enforces the use of 'probably_valid_to'.
In other words, afaict, the current code computes the difference
between the number of bytes that have been played from the input
source stream (buf_writepos) and the end of the data the app has
written (probably_valid_to). It then clips the mixing length to
But what it should really be interested is the amount of as yet
unmixed data in the source stream buffer, and that would be
properly computed by taking the difference of probably_valid_to
Does that make sense?
More information about the wine-devel