Clamp timestamp interpollation to 0 to avoid going negative. This should not
happen, really, but until the interpolation is improved this seems better.
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
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
We need to mark our clock as using some other clock source. Alsa source uses the
clock type to decide if it can use alsa driver timestamps or not.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690465
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
This reverts commit e39fbe6b7e.
Looks like we need to pass the full .la file after all in a setup
with libtool, or it might not find the library, e.g. like
ERROR: can't resolve libraries to shared libraries: gstfft-1.0
Conflicts:
gst-libs/gst/audio/Makefile.am
gst-libs/gst/pbutils/Makefile.am
Also see https://bugzilla.gnome.org/show_bug.cgi?id=603710
These are now converted into silence buffers if they have
a duration or cause the ringbuffer and clock to be started
if they don't have a duration.
Fixes bug #685273.
Just change default value, since we also don't want to fail
if we want to deactivate and aren't active or want to activate
and are already active.
https://bugzilla.gnome.org/show_bug.cgi?id=685490
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.
