[PATCH 1/2] winepulse.drv: Adjust the buffer volume before sending it to PulseAudio

[Gabriel Ivăncescu]

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?