[Bug 28039] New: IAudioClock_GetPosition must ignore underruns (MacOS)

http://bugs.winehq.org/show_bug.cgi?id=28039

Summary: IAudioClock_GetPosition must ignore underruns (MacOS)
           Product: Wine
           Version: 1.3.25
          Platform: x86
        OS/Version: Mac OS X
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: mmdevapi
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

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, 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.
See bug #27937 comment #1 and 2 for log snippets.

On MacOS, GetPosition appears to continue to grow in the presence of underruns,
violating 2 and 3.  Hence the name of the present issue.

Note that underruns are unknown to WINMM. A perfectly legal use is:
waveOutOpen()
waveOutPrepare(hugeboomheader)
waveoutPrepare(clickheader)
waveoutPrepare(ouchheader)
waveoutPrepare(beepheader)
then write the headers as the conditions arise (arguably dsound's mixing would
be more adequate).  Guess what happens when GetPosition grows playing nothing
between 2 beeps?