http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #134 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-27 04:49:17 CST --- Initially I thought we need EVENTCALLBACK timing tests. It turns out that the current test_worst_case is good enough for reasoning on averages: render.c:2080: Should play 1000ms continuous tone with fragment size 441. render.c:2132: Released 44100=100x441 -441 frames at 44100 worth 990ms in 1006ms
- If the events were more than ~10ms apart, total time would be >> 1006ms, e.g. ~1200ms on my 12ms callback wakeup Intrepid system.
- If the events were < ~10ms apart, it would take less time or be unable to release data 100 times, e.g. 80 times on my Ubuntu system with 8ms wakeups, or leave more padding at the end.
Now is the rate 10ms or 10.1587? I'm researching opportunities for allowing a regular drain (e.g. decrease padding by one period each time) even in the presence of irregular or non-matching callback intervals, given that we have a few frames hidden within ALSA that hopefully will compensate that. Ideas & help welcome.