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.
So that pulsesrc/pulsesink get chosen over other possible PRIMARY
src/sinks by autoaudiosink. Presumably, if pulse is available, it
is always preferred over another src/sink.
Fixes: #647540.
This drops support fof PulseAudio versions prior to 0.9.16, which was
released about 1.5 years ago. Testing with very old versions is not
feasible and we don't want to maintain 2 independent code-paths.
Don't use g_assert() for error handling, even if they're highly unlikely.
Either we *know* that something can't happen, in which case we
should just not handle it, or we think something can happen, but it is
very very unlikely that it will ever happen, in which case we should
handle it like any other error instead of asserting.
g_assert() is best left for conditions we have control of, like checking
internal consistency of our code, not checking return values of external
code.
Fixes a bunch of warnings when compiling with -DG_DISABLE_ASSERT:
gstrtpgsmpay.c: In function 'gst_rtp_gsm_pay_handle_buffer':
gstrtpgsmpay.c:130:17: warning: variable 'rtpgsmpay' set but not used
gstspeexenc.c: In function 'gst_speex_enc_encode':
gstspeexenc.c:904:19: warning: variable 'written' set but not used
pulsesink.c: In function 'gst_pulsesink_change_state':
pulsesink.c:2725:9: warning: variable 'res' set but not used
pulsesrc.c: In function 'gst_pulsesrc_change_state':
pulsesrc.c:1253:7: warning: variable 'e' set but not used
GCC 4.6.x spits warnings about such usage of variables. The variables in
raw1394 were marked with G_GNUC_UNUSED as this seemed omre appropriate.
The others were removed.
Pulsesink was recently changed to defer uncorking until there is data
to write. This condition will however never occur when EOS in being
rendered (since that marks the end of data). Changing to PAUSED state
while EOS is being waited on results in a hang: pausing corks the
stream, which will never be undone since there is no more data when
going back to PLAYING. If pulsesink is the clock provider, deadlock
ensues since time doesn't continue in corked state and the clock id
for EOS wait never fires.
Fixes#645961.
Not doing so can result in a deadlock when two threads enter
gst_pulseringbuffer_open_device at the same time, as
pa_threaded_mainloop_wait releases the mainloop lock while waiting,
allowing another thread to take it, resulting in a deadlock as two
threads waits for the lock the other is holding.
https://bugzilla.gnome.org/show_bug.cgi?id=643087
By allowing larger chunks to be sent, PulseAudio will have a
lower CPU usage. This is especially important on low-end machines,
where PulseAudio can crash if packets are coming in at a higher
rate than PulseAudio can process them.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
After starting the ringbuffer, we wait for enough data to arrive before
uncorking the stream. This will cause the pipeline to stall if we get an
EOS (or otherwise need to flush the stream) before sufficient data
becomes available. This patch makes sure that the stream is uncorked
while flushing to avoid this problem.
Fixes issue with a webkit unit test testing reverse playback of
an MP4 H.264/AAC file.
https://bugzilla.gnome.org/show_bug.cgi?id=639740
This makes the call to pa_stream_cork() during ringbuffer pause()
synchronous, which makes sure that the clock does not advance after we
take a snapshot for start_time.
https://bugzilla.gnome.org/show_bug.cgi?id=639240
* ext/pulse/pulsesrc.c (gst_pulsesrc_class_init, gst_pulsesrc_init)
(gst_pulsesrc_set_property, gst_pulsesrc_get_property)
(gst_pulsesrc_open): Add a "client" property, as in pulsesink.
Fixes#634914
Don't uncork in the _start method just yet but wait until we have written some
samples to pulseaudio. This avoid underruns on pulseaudio and less crackling
noises when starting.
Make the is_dead check more clear and add an option to check for the status of
the stream in addition to the context.
We don't need a stream to get the device_description string.
Fixes#630317
We also need to share the main-loop threads as this owns the context. Thus have
a class wide main-loop thread. From this we create a context per client-name.
Instead of always looking up the context, we keep this with the instance. The
reverse mapping is only needed in pulse singal handlers. This saves a lot of
locking. Also one signal handler becomes simpler as ther eis only one mainloop
to notify.
Now valgind happy - no leaks, no bad reads/writes.
This reverts major parts of commit 69a397c32f.
Fixes#628996
Use g_slist_prepend as we don't care about the order. Check for list == NULL
instead of iterating the list to see if it is empty. Move ctx allocation down
to prevent leak in case of failure.
Don't leak the pulsesink element by having the clock keep a ref to the sink.
Create the clock only once in the constructor and use the baseaudiosink clock
cleanup code.
Allows the application to modify the client name used to connect when
connecting to the PulseAudio daemon. Note however that updating the
property after the element reached the READY state will have no
effect until the next NULL->READY transition.
Fixes bug #627174.
Avoid to create a new PA context for each new client by using a hash
table containing the list of ring-buffers and the shared PA context
for each client. Doing this will improve application memory usage in
the cases where multiple pipelines involving multiple pulsesink
elements are used.
Fixes bug #624338.
If the application requests a state-change and pulsesink fails to open
the ring_buffer device the mainloop attribute of the sink should be
cleaned up to avoid future state-change (NULL->READY) failures.
The existing get_type() implementation is racy, and the
g_type_class_ref() workaround didn't actually work because
it was in the wrong function. Since class creation in GObject
is thread-safe these days (since 2.16), the class_ref workaround
is no longer needed and it is sufficient to ensure the _get_type()
function is thread-safe, which G_TYPE_DEFINE does.
https://bugzilla.gnome.org/show_bug.cgi?id=624338
when we are shutting down, we might still receive state updates from pulseaudio
but since we are unparented we should not do anything with the NULL parent
anymore.
Use the acquired field of the ringbuffer in get_time to know when we are in an
invalid state. We don't clear the rate flag when releasing the ringbuffer so
this values is not usable.
Avoids some error messages being posted because the pulseaudio connection is
down.
Generally decisions on the volume of the stream should be done inside of
PA, not inside of Gst. Only PA knows how volumes translate between
devices and s on.
This patch makes sure that all volumes set via the volume property are
only applied *once* to the underlying stream. After applying them the
client side will not store them anymore. This should make sure that
really only user-triggered volume changes are forwarded to server, but
the client never tries to save/restore the volume internally.
Fixes bug #595231.
pthread does not guarantee that there are no spurious condition variable
wakeups, neither does pa_threaded_mainloop_xxx() which is a wrapper
around it. So we need to loop around the _wait() function to make sure
we get the right wakeup.
Also, unify the order of the wait loops across the file.
If we let the daemon decide freely by passing -1, we end up always getting 20ms.
We want to set this value because in some cases we want to select a higher
latency-time in order to save power.
Fixes#597601
In case that the pulse daemon runs the source device at a relatively low fixed
fragment size compared to the requested latency-time, configure the ring buffer
segsize to the largest integer multiple of the fragment size that is still
smaller than or equal to the requested latency-time.
Fixes bug #597463.
Remove the code to deal with a ringbuffer reset as this code is now in the base
class.
Bump the -base requirement as we need the new baseaudiosink code to function
properly.
Set the default slave method to the much better skew algorithm. This is the
default in the new base class but we override this here as well for the
upcomming release.
Otherwise that code will just be expanded to nothing when compiled
-DG_DISABLE_ASSERT (PS: why is mainloop_start() called in the init
function and not when changing state to READY?)
Keep track of the paused state of the source and leave the read function when
paused.
don't wait for a latency update when the delay is not yet known but simply
return 0 instead of blocking.
Keep track of the corked state of the stream.
Fix the state changes.
We can't wait for the ENTER/LEAVE messages to be be posted because the base
class sometimes calls the start method with the object lock, which would block
the message posting.
Instead, just assume that the message will be posted soon and continue. We'll
have to fix this in the base class.
Emit stream-status messages for the pulse thread.
Don't use our own GCond for signaling but simply use the pulse mainloop
mechanisms for synchronisation.
See #587695
Upper volume limmit was 1000. That appear unneceasrily high. It would also cause
sever distortion if accidentialy used. Now its 10 (~ +15db) which is also in
sync with volume and playbin2.
Since we map the ringbuffer to the pulseaudio internal ringbuffer, flush the
pulseaudio buffer when we are asked to clear the ringbuffer.
This avoids some leftover audio after a seek.
Hack around thread-safety issues in GObject and our racy _get_type()
functions (we could easily fix the _get_type() functions, but we still
need to hack around the GObject class races until we require a newer
GLib version, I think).
First we ignore request to fill the ringbuffer which are less then a segment.
The small request where causing stutter.
Then we disable flushing the stream when running against pa 0.9.12 as this
triggers an assertiong in the sound server and terminates it. It does not happen
with 0.9.10 and 0.9.14.
We can use prebuf = 0 to instruct pulse to not pause the stream on underflows.
This way we can remove the underflow callback. We however have to manually
uncork the stream now when we have no available space in the buffer or when we
are writing too far away from the current read_index.
when we switch streams, the clock will reset to 0. Make sure that the provided
clock doesn't get stuck when this happens by keeping an initial offset. We also
need to make sure that we subtract this offset in samples when writing to the
ringbuffer.
If the caps changes, the sink is reset without transitioning through
a PAUSED->PLAYING state change, resulting in a corked stream. This avoids
the problem by checking that the stream is uncorked when writing samples
to it.
When trying to write out a segment, wait until there is enough free space
for the entire segment. This helps to reduce ripple in the clock reporting,
where the app might query the playback position while only half a segment
has been written (and is therefore reported by _delay(), even though
the ring buffer has not yet been advanced)
g_atomic_int_(get|set) only work on ints and the flags are
an enum (which on most architectures is stored as an int).
Also the way the flags were accessed atomically would still
leave a possible race condition and we don't do it in any
other mixer track implementation, let alone at any other
place where an integer could be changed from different
threads. Removing the g_atomic_int_(get|set) will only
introduce a new race condition on architectures where
integers could be half-written while reading them
which shouldn't be the case for any modern architecture
and if we really care about this we need to use
g_atomic_int_(get|set) at many other places too.
Apart from that g_atomic_int_(set|get) will result in
aliasing warnings if their argument is explicitely
casted to an int *. Fixes bug #571153.
rather than PA thread.
pa_threaded_mainloop_lock() (a.o.) and by extension get_property should
not be done from a PA thread, but the latter may occur as a result of a
property change notification. Fixes#571204 (though current situation
not ideal, e.g. post message rather than signal).
