http://bugs.winehq.org/show_bug.cgi?id=28047
Summary: IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse) Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
GetPosition is critical because the new "winmm on mmdevapi" layer relies on it for its buffer management. Currently, neither winealsa nor winecoreaudio entirely fulfill GetPosition's contract.
GetPosition yields "the stream position of the sample that is currently playing through the speakers". My tests show that it ignores underruns and is therefore not identical to a clock. One can derive at least 2 tests from that:
1. GetPosition <= elapsed time * samples/sec (cannot hear the future). 2. GetPosition <= sum of samples fed to the device. 3. GetPosition == sum of samples once all have been played. 4. Getposition is monotically increasing (except when Reset).
Actually GetPosition does not yield samples (rather than time, which will be important the day Wine implements the SetSampleRate API), replace the above with GetPosition / GetFrequency * samples per sec to be correct.
My tests attached to bug #27937 show that: - winecoreaudio fails test 3 (then 2). - winealsa with dmix fails test 1 during the first seconds of play. - winealsa with pulse fails test 1 much worse because it buffers more. See bug #27937 comment #1 and 2 for log snippets.
snd_pcm_delay must be used to get the speaker position, as I noted in http://www.winehq.org/pipermail/wine-devel/2011-August/091371.html
Unfortunately, GetPosition in winealsa.drv/mmdevdrv.c instead uses snd_pcm_avail_update, returning not the position of the sample currently playing rather than some number related to how much data was buffered, i.e. it is ahead of time. Hence the name of the present issue.