[Bug 28047] New: IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse)

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Aug 10 11:34:57 CDT 2011


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 at winehq.org
        ReportedBy: hoehle at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list