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



Reply via email to