audiosink: compensate for segment restart with clock's time_offset

When playing chained data the audio ringbuffer is released and
then acquired again. This makes it reset the segbase/segdone
variables, but the next sample will be scheduled to play in
the next position (right after the sample from the previous media)
and, as the segdone is at 0, the audiosink will wait the duration
of this previous media before it can write and play the new data.

What happens is this:
pointer at 0, write to 698-1564, diff 698, segtotal 20, segsize 1764, base 0

it will have to wait the length of 698 samples before being able to write.

In a regular sample playback it looks like:
pointer at 677, write to 696-1052, diff 19, segtotal 20, segsize 1764, base 0

In this case it will write to the next available position and it
doesn't need to wait or fill with silence.

This solution is borrowed from pulsesink that resets the clock to
start again from 0, which makes it reset the time_offset to the time
of the last played sample. This is used to correct the place of
writing in the ringbuffer to the new start (0 again)

https://bugzilla.gnome.org/show_bug.cgi?id=737055
This commit is contained in:
Thiago Santos 2014-09-23 14:14:36 -03:00
parent 00b43badc7
commit 8242676dc2

View file

@ -399,6 +399,7 @@ gst_audio_sink_ring_buffer_acquire (GstAudioRingBuffer * buf,
GstAudioSink *sink;
GstAudioSinkClass *csink;
gboolean result = FALSE;
GstAudioClock *clock;
sink = GST_AUDIO_SINK (GST_OBJECT_PARENT (buf));
csink = GST_AUDIO_SINK_GET_CLASS (sink);
@ -408,6 +409,10 @@ gst_audio_sink_ring_buffer_acquire (GstAudioRingBuffer * buf,
if (!result)
goto could_not_prepare;
/* our clock will now start from 0 again */
clock = GST_AUDIO_CLOCK (GST_AUDIO_BASE_SINK (sink)->provided_clock);
gst_audio_clock_reset (clock, 0);
/* set latency to one more segment as we need some headroom */
spec->seglatency = spec->segtotal + 1;