directsoundsrc: provided clock is not monotonic after pause and resume

Submitted by Philippe Renon

Link to original bug (#788362)

Description

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

Version: 1.12.3