On 5/17/19 7:34 PM, Andrew Eikum wrote:
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
Sorry I didn't have time to reproduce it earlier, will try tomorrow, but from your log there's no doubt that the last frame is truncated and has only one channel. The stream is clearly stereo and yet the number of bytes is odd.
I didn't know this was even possible, I'll try to investigate why it happens. I mean, fixing the buffer overflow is not a big deal itself, but my concern is that if a write can end on a truncated frame, then it can also begin on a truncated frame, which really complicates stuff (since we won't start from the first channel, somehow have to track it)...
FWIW the ALSA patch doesn't have this problem because it works with "frames" instead of "bytes" so it's always ending on a complete frame boundary. When you use ALSA, it works fine, right?