man, 28,.02.2005 kl. 11.23 -0600, skrev Jeremy White:
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.
It is true that probably_valid_left is the distance between writepos and probably_valid_to, and that this is used to cut off the mixlen. But the original mixlen (before cutting it) is *also* measured from the writepos (in the primary buffer's frame of reference, of course). The value you're apparently after, the amount of as yet unmixed data, is computed from the mixlen shortly after this, by subtracting primary_done (done above the "remaining mixlen" trace). So this should already be taken care of.