All the GstAudioClock method declarations required object of GstClock type
as a first argument, but in fact, required GstAudioClock object (runtime
check in function body). Instead of checking type in run-time, we can
change functions declaration, to accept only GstAudioClock methods. Then,
runtime check is not necessary anymore, since always GstAudioClock object
is passed to a function.
https://bugzilla.gnome.org/show_bug.cgi?id=756628
The implementation of that vfunc might want to use the object lock for
something too. It's generally not a good idea to keep the object lock while
calling any function implemented elsewhere.
Also the ringbuffer can only be NULL at this point, remove a useless if block.
And in the sink actually hold the object lock while setting the ringbuffer on
the instance. Code accessing this is expected to use the object lock, so do it
here ourselves too.
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Port a change from audiobasesink from def07410, to ignore setcaps
when the caps don't actually change, and avoid a reconfiguration
and reset of the ringbuffer in that case.
ringbuffer was released after setting values to its spec field
in gst_audio_base_src_setcaps(). This led to failure in case
gst_audio_base_src_setcaps() is called more than one time.
https://bugzilla.gnome.org/show_bug.cgi?id=696540
Use new ringbuffer ERROR state to make all the various
threads bail out correctly when the subclass posts an
error. It's a bit iffy to communicate this properly
between the different bits of code.
https://bugzilla.gnome.org/show_bug.cgi?id=690197
In SKEW mode, use next_sample == -1 to check for the first sample
when starting to read samples so it resyncs the ringbuffer and
timestamps are ok.
Suggestion from Teemu Katajisto <teemu.katajisto@digia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=648359
Only provide a clock when we are not flushing, this means that we have posted a
PROVIDE_CLOCK message. We used to check if we were acquired but that doesn't
work anymore now that we do the negotiation async in the streaming thread: it's
possible that we are still negotiating when the pipeline asks us for a clock.
Make it possible for subclasses to provide the timestamp (as an absolute time
against the pipeline clock) of the last read data.
Fix up alsa to provide the timestamp received from alsa. Because the alsa
timestamps are in monotonic time, we can only do this when the monotonic clock
has been selected as the pipeline clock.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=635256
