When we explicitely set the mute property to FALSE, connect to pulseaudio with
the PA_STREAM_START_UNMUTED flag set, otherwise pulseaudio will use its
previously used value (which might start the stream muted).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=672401
pulseaudiosink breaks visualisations in its current form, so let's
prevent it from being autoplugged for the time being.
The best we can hope to do in the 0.10 series is query the list of
available sinks and their formats, and expose these as the bin's sinkpad
caps. While this is not a comprehensive solution, it will make sure that
we're only trying to support compressed formats if we're certain that
one exists.
The long-term fix for this will be in the form of proper upstream
renegotiation support in the 0.11/1.0 series.
https://bugzilla.gnome.org/show_bug.cgi?id=666361
pa_stream_* functions return negative on error, despite the defines
for error codes being positive.
I only got to repro the error twice, so I'm not sure 100% sure this
fixes the issue (the negative var being uninitialized after returning
from pa_stream_get_latency).
This is causing us lots of headaches in 0.10 and needs to be done
differently and properly in 0.11. playbin or decodebin should
reconfigure themselves based on reconfigure events, for example.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Conflicts:
ext/pulse/pulseaudiosink.c
ext/pulse/pulsesrc.c
gst/audioparsers/gstaacparse.c
gst/audioparsers/gstamrparse.c
gst/audioparsers/gstdcaparse.c
gst/audioparsers/gstflacparse.c
gst/effectv/gstradioac.c
gst/effectv/gstradioac.h
gst/effectv/gstripple.c
Some possible FIXMEs remaining in the audio parser getcaps functions.
PulseAudio 1.0 supports per-source-output volumes, and this exposes the
functionality via the GstStreamVolume interface.
When compiled against pre-1.0 PulseAudio, the interface is not
implemented, and the "volume" or "mute" properties are not available.
This bit of ugliness will go away when we can depend on PulseAudio 1.0
or greater.
https://bugzilla.gnome.org/show_bug.cgi?id=595055
This introduces a new bin which wraps around pulsesink and depending on
the formats supported by the sink, plugs in/out a decodebin2 as
required. This allows users to switch sinks on the stream and adapts
accordingly (for example, you could watch a movie in passthrough mode on
your receiver which supports AC3 decode, then plug out and switch to a
non-digital profile to continue uninterrupted on analog output).
The bin is required because doing the same with playbin2/playsink will
require API changes that cannot be made in 0.10. With 0.11/1.0, we
should be able to ask for upstream caps renegotiation to deal with all
this.
https://bugzilla.gnome.org/show_bug.cgi?id=657179
There's no use in splitting the incoming data down to the segsize
limit - by writing as much as possible in one chunk, we increase
performance and avoid PulseAudio unnecessary rewinds.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Sine the base class now does the negotiation from the streaming thread we have
to be careful and check if the stream is ready before changing its corked state.
This adds support for various compressed formats (AC3, E-AC3, DTS and
MP3) payloaded in IEC 61937 format (used for transmission over S/PDIF,
HDMI and Bluetooth).
The acceptcaps() function allows bins to probe for what formats the sink
being connected to support. This only works after the element is set to
at least READY.
If the underlying sink changes and the format we are streaming is not
available, we emit a message that will allow upstream elements/bins to
block and renegotiate a new format.
This exposes the source output index of the record stream that we open
so that clients can use this with the introspection if they want (to
move the stream, for example).
Since commit 8bfd80, gst_pulseringbuffer_stop doesn't wait for the
deferred call to be run before returning. This causes a race when
READY->NULL is executed shortly after, which stops the mainloop. This
leaks the element reference which is passed as userdata for the callback
(introduced in commit 7cf996, bug #614765).
The correct fix is to wait in READY->NULL for all outstanding calls to
be fired (since libpulse doesn't provide a DestroyNotify for the
userdata). We get rid of the reference passing from 7cf996 altogether,
since finalization from the callback would anyways lead to a deadlock.
Re-fixes bug #614765.
