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 correct.
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 that size.
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 and dsb->buf_mixpos.
Does that make sense?
Cheers,
Jeremy