On Fri, May 17, 2019 at 07:23:42PM +0300, Gabriel Ivăncescu wrote:
On 5/17/19 5:07 PM, Andrew Eikum wrote:
On Wed, May 08, 2019 at 03:49:15PM +0300, Gabriel Ivăncescu wrote:
Only fixes the PulseAudio driver for the first bug, not ALSA.
Sorry for the long delay in reviewing this. This crashes the King of Dragon Pass demo for me. Looks like we're not ending the inner do-while loop in the U8 case somehow, so it runs past the end of the buffer.
Andrew
Hi Andrew, thanks for the review. That's definitely weird, since it's 1 byte per sample, the only way it can happen is if the buffer is truncated in terms of channels (so e.g. for stereo, an odd amount of bytes, last sample only has left channel).
Can you please add a quick TRACE before the loop, and tell me what are the values of 'channels' and 'bytes' before it crashes? (or just send me the log)
Are you unable to reproduce it? The bug links to the demo files. It reproduces every time for me.
FWIW here's the debug printing I used:
Before the loop: 002d:err:pulse:write_buffer beg: 0x770c7028, end: 0x770c78c5
At the end of the loop body: 002d:err:pulse:write_buffer p: 0x770c702a 002d:err:pulse:write_buffer p: 0x770c702c 002d:err:pulse:write_buffer p: 0x770c702e ... 002d:err:pulse:write_buffer p: 0x770c78be 002d:err:pulse:write_buffer p: 0x770c78c0 002d:err:pulse:write_buffer p: 0x770c78c2 002d:err:pulse:write_buffer p: 0x770c78c4 002d:err:pulse:write_buffer p: 0x770c78c6 <-- we're past end at this point 002d:err:pulse:write_buffer p: 0x770c78c8 ... goes on forever
Andrew