winepulse test data review

[Maarten Lankhorst]

Op 04-12-12 14:28, Joerg-Cyril.Hoehle at t-systems.com schreef:
> Hi,
>
> Maarten Lankhorst wrote:
>> Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too,
> Yes, I wanted to go no further than 8ms below the 10ms period limit.
>
>> it was just the mixing of various levels of sleep that was failing. Not sure why though,
>> might be something about the scheduling throwing it off.
> There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio.
> It goes as follows.
>
> IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine,
> regardless of how accurate or "improved" GetPosition is.
>
> winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss.
>
> Consider the sleep sequence 0 5 8 0 5 ms...
>
> + The transition 8 -> 0ms sleep is fine, as data is sent 2ms after the prior packet
>
> - The transition 0 -> 5 is most problematic, as it means that 2 ReleaseBuffer
>   will be 15ms apart, even though only 10ms of data was sent.
>
> I believe winepulse is affected by this too, like winecoreaudio.
>
> The stable sequences "always 0" or "always 8ms sleep" are paced regularly, so underruns
> are avoided as long as the OS schedules the threads soon enough.
>
>
> Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries,
> -- like native presumably does.
>
>
> winecoreaudio solution paths:
>  - write packets on period tick, not at release time
>  - or add silence lead-in
>  - or delay first packet until period tick only (if small)
>  - or ...
>
> I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio
> yet maintain their current "send packet" codebase instead of transitioning to a separate buffer
> that winealsa and wineoss use.
>
Actually, Arun Raghavan found this thread and pointed me towards 
updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0:

Op 20-12-12 12:43, Arun Raghavan schreef:
> Hi Maarten,
> While following some random thread, I cam across this:
> 
> http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html
> 
> I see you mention:
> 
> """
> I may also be hitting some pulseaudio bug though, if I play some music on the background when one
> of those tests start the sound during the test works ok, even if I pause it after that.
> """
> 
> We recently fixed a bug where pausing and resuming a stream could end up
> adding a hidden latency to the stream, and this would not happen if
> another stream was playing. The fix is in 3.0, so if this is what you
> were referring to, might be worth trying with newer PA.

This does make my life a lot easier though, as finding a way to only queue on multiple
of periods was giving me a headache, results from 10 seconds now:

render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 10000ms in 9991ms
render.c:2238: Should play 1000ms continuous tone with fragment size 441.
render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms
render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped.

I would be interested in the exact commit though, so I can get it backported to
precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one
that might have been hitting this problem.

~Maarten