winepulse test data review

[Arun Raghavan]

On Thu, 2012-12-20 at 13:34 +0100, Maarten Lankhorst wrote:
> 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:

That's good to hear.

> 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.

The bug becomes really visible when your stream requests a high latency
(and no other stream with a lower latency request is connected, like the
music player or Flash). This is the commit of interest to you:

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=29f064aa3d3a83e275361aad3f9e7efdc84b8ad0

Cheers,
Arun