Op 04-12-12 14:28, joerg-cyril.hoe...@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