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
flacdec converts the src timestamp to a sample number, uses that internally, then reconverts the sample number to a timestamp for the output buffer. Unfortunately, sample numbers can't be represented in an integer number of nanoseconds, and the conversion process was truncating rather than rounding, resulting in sample numbers and output timestamps that were often off by a full sample.
This corrects the time->sample convesion
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>
The libFLAC API is callback based, and we must only call it to
output data when we know we have enough input data. For this
reason, a single processing step is done when receiving a buffer.
However, if there were metadata buffers still pending, a step
intended for the first audio frame might end up writing that
leftover metadata. Since a single step is done per buffer, this
will cause every buffer to be written one step late.
This would add some latency (a bufferfull's worth), possibly
lose a buffer when seeking or the like, and also cause timestamp
and offset to be applied to the wrong buffer, as updates to
the "current" segment last_stop (from incoming buffer timestamp)
will be applied to an output buffer originating from the previous
incoming buffer.
This fixes the issue by ensuring that, upon receiving the first
audio frame, processing is done till all metadata is processed,
so the next "single step" done will be for the audio frame. After
this, we should keep to 1 input buffer -> 1 output buffer and so
avoid getting out of sync.
https://bugzilla.gnome.org/show_bug.cgi?id=650960
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.
For some reason, in code dating to 2001, encoded jpeg buffers were
rounded up to multiples of 4 bytes. With the added bonus that the
extra bytes are unwritten, causing valgrind issues. Oops. I can't
think of any reason why JPEG buffers need to be multiples of 4 bytes,
so I removed the padding. There might be some code somewhere that
depends on this behavior, so if this needs to be reverted, please fix
the valgrind issues.
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.
Not doing so will cause buffers to be received by downstream without
a time base set.
We use the same method avimux uses to get access to the event when
collectpads got the sink event function.
https://bugzilla.gnome.org/show_bug.cgi?id=640323
