Now we can configure how much time to wait before deciding that a
discont has happened.
Also, adds getter and setter to allow derived implementations to set
this value upon construction.
Suggestions and several improvements by Havard Graff.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
A common problem for audio-playback is that the timestamps might not
be completely linear. This is specially common when doing streaming over
a network, where you can have jittery and/or bursty packettransmission,
which again will often be reflected on the buffertimestamps.
Now, the current implementation have a threshold that says how far the
buffertimestamp is allowed o drift from the ideal aligned time in the
ringbuffer. This was an instant reaction, and ment that if one buffer
arrived with a timestamp that would breach the drift-tolerance, a resync
would take place, and the result would be an audible gap for the
listener.
The annoying thing would be that in the case of a "timestamp-outlier",
you would first resync one way, say +100ms, and then, if the next
timestamp was "back on track", you would end up resyncing the other way
(-100ms) So in fact, when you had only one buffer with slightly off
timestamping, you would end up with *two* audible gaps. This is the
problem this patch addresses.
The way to "fix" this problem with the previous implementation, would
have been to increase the "drift-tolerance" to a value that was greater
than the largest timestamp-outlier one would normally expect. The big
problem with this approach, however, is that it will allow normal
operations with a huge offset timestamp vs running-time, which is
detrimental to lip-sync. If the drift-tolerance is set to 200ms, it
basically means that lip-sync can easily end up being off by that much.
This patch will basically start a timer when the first breach of
drift-tolerance is detected. If any following timestamp for the next n
nanoseconds gets "back on track" within the threshold, it has basically
eliminated the effect of an outlier, and the timer is stopped. If,
however, all timestamps within this time-limit are breaching the
threshold, we are probably facing a more permanent offset in the
timestamps, and a resync is allowed to happen.
So basically this patch offers something as rare as both higher
accuracy, it terms of allowing smaller drift-tolerances, as well as much
smoother, less glitchy playback!
Commit message and improvments by Havard Graff.
Fixes bug #640859.
This allows subclasses to provide a "payload" function to prepare
buffers for consumption. The immediate use for this is for sinks that
can handle compressed formats - parsers are directly connected to the
sink, and for formats such as AC3, DTS, and MPEG, IEC 61937 patyloading
might be used.
API: GstBaseAudioSinkClass:payload()
https://bugzilla.gnome.org/show_bug.cgi?id=642730
Given a large enough drift-tolerance, one could end up in a situation
where one would keep aligning the written buffers behind the current
read-segment position. The result for the reader would be complete
silence, possible preceded by very choppy audio.
By checking the available headroom, one can determine if there is
room to do alignment, or if one should resort to a resync instead to get
the pointers back on track.
Also refactor the alignment-logic out of the render function for cleaner
code.
Commit ba2e500bd9 ensured to provide
a running clock when EOS had finished rendering. However,
other measures are needed (and were in place before) to ensure a
running clock when EOS still needs rendering (i.e. waiting).
So, specifically, re-introduce eos_rendering removed in aforementioned commit,
this time as a public variable so subclasses can be aware of the situation.
Fixes (part of) #645961.
API: GstBaseAudioSink:eos_rendering
Observed a case where the sink went to null-state during the query,
hence the ringbuffer-pointer was NULL, causing a crash.
Moving the ringbuffer-check code until after the query, and hold the
lock during the check and while using the spec-values. It should not matter
to the query wether the ringbuffer is present or not, and it actually
gets a time bit more time to get the ringbuffer set up in this case!
Fixes#635231
So run-time bindings can introspect the names correctly (we abuse this
field as description field only in elements, not for public API
(where the description belongs into the gtk-doc chunk).
https://bugzilla.gnome.org/show_bug.cgi?id=629746
Don't take an extra ref on the sink and source because that creates a reference
cycle. Instead, use the invalidate method of the clock when the sink and source
are freed. This way, we don't call into the time function anymore after the
objects are disposed.
This reverts commit cea2644ed8.
Many audio sink assume that they can create a clock in
the instance init function and it will be there forever
and not be cleared by the state change functions.
Increase default drift tolerance to 40ms to avoid glitches with decoders
or formats where there's a lot of timestamp jitter for some reason or
another (in this case: asf/wma), at least until we implement timestamp
smoothing.
Our calibration against the pipeline clock is done with the adjusted
ringbuffer time, so take the adjustement into account. Fixes some audio dropouts
when reusing audio sinks after switching clocks and slaving methods in a
pipeline.
When we are calibrating the internal clock against the external clock take into
account the time offset applied to our internal clock because we will subtract
that in the render_function again.
Add drift-tolerance property (defaulting to 20ms) to handle resync after clock
drift or timestamp drift instead of relying on the latency-time value for clock
drift and 500ms for timestamp drift.
Remove warning about discont timestamp and simply resync. The warning is in some
cases not correct and is triggered more frequently now that we lower the
tolerance value.
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a sixteenth of a polar bear.
Check for pulsesink < 0.10.17 because it includes code that is now included in
baseaudiosink. Disable that code in baseaudiosink to be compatible with the
older version.
Take the time of the clock so that the last_time field is set. This is important
for sinks that restart their internal ringbuffer after a caps change and need to
know the last know position.
When going to NULL, we reset the ringbuffer so that it starts beck from 0. We
also make sure that the clock is updated with the elapsed time so that it
alsways increments even when the ringbuffer goes back to 0. When this happened
we need to adjust the sample position for the reset ringbuffer.
Fixes#594136
Unparent and free the ringbuffer when going to NULL, like we do with the
audiosrc element. We can do this now because we correctly manage the time
jumping back to 0.
