winepulse test data review

[Joerg-Cyril.Hoehle at t-systems.com]

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.

Regards,
 Jörg Höhle