[Bug 788362] New: directsoundsrc: provided clock is not monotonic after pause and resume

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788362

            Bug ID: 788362
           Summary: directsoundsrc: provided clock is not monotonic after
                    pause and resume
    Classification: Platform
           Product: GStreamer
           Version: 1.12.3
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: philippe_renon at yahoo.fr
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Video playback with audio jumps forwards visibly when going from pause to
plauing.

This is a log extract of a video playback going from playing to pause and back
to playing.
The shows the out of audiobasesink
gstaudiobasesink.c:545:gst_audio_base_sink_get_time:<directsoundsink0>
The time displayed on the far right is the time that will feed the audio clock
that drives the pipeline.

0:00:02.432044715   processed samples: raw 30240, delay 9600, real 20640, time
0:00:00.430000000
0:00:02.437322934   processed samples: raw 30720, delay 9600, real 21120, time
0:00:00.440000000
Pausing...
0:00:02.437831207   processed samples: raw 30720, delay 9600, real 21120, time
0:00:00.440000000
0:00:02.438205430   processed samples: raw 30720, delay 9600, real 21120, time
0:00:00.440000000
0:00:02.438512938   processed samples: raw 31200, delay 0, real 31200, time
0:00:00.650000000 (1)
Playing...
0:00:05.773609712   processed samples: raw 31200, delay 0, real 31200, time
0:00:00.650000000
0:00:05.774203007   processed samples: raw 33600, delay 2880, real 30720, time
0:00:00.640000000 (2)
0:00:05.774348849   processed samples: raw 40800, delay 9600, real 31200, time
0:00:00.650000000

You can see at (1) that the clock jumps forward by more than 200ms.
At (2) it goes back in time by 10ms.

The audio clock time is computed by GstAudioBaseSink based on where it thinks
it is (number of samples sent to the device)
minus the delay (number of samples not yet played by the device). The delay is
provided by the directsoundsink.

The problem is that when pausing, directsoundsink resets the DirectSoundBuffer
and the delay becomes zero.
This explains the jump forward of the clock. Fixing this is not too complex:
don't reset the DirectSoundBuffer and pause it instead.

But that requires that directsoundsink can distinguish a pause from a stop.
Currently pause and stop are not exposed to audiosink children and are handled
by the same reset vmethod.

A patch to expose the pause and stop vmethod is provided here
https://bugzilla.gnome.org/show_bug.cgi?id=788361

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.