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.
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