If we did not know how many frames to expect, then we get an unexpected
end of stream when trying to decode more frames that are there, if there
are leftover bits to pad to the next byte
Looking at the remaining bits in the bitstream after decoding a
single frame can't be used as loop condition. The remaining
bits might not give a complete frame and the speex decoder will
then output nothing but access uninitialized memory, which leads
to valgrind warnings.
Fixes bug #644669.
Allows applications to connect to the "draw" signal of
the element and do their custom drawing there.
Includes an example application demonstrating usage.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=595520
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
Error out when we are asked to read a different size that what was configured as
the jack period size because that would mean something else is wrong.
Fixes#618409
Not only adjust buffer-time and avoid segtotal=0, but instead ensure segtotal is
atleast 2. Do same change on jacksrc. We could also check the latency and buffer
time configured by the client and adjust buffer-time so that we get to the same
number of segments.
Jack overrides user-specified latency-time with the one it gets from jack
itself. It also needs to adjust buffer-time somewhat to avoid segtotal being 0
The gst_jack_audio_client_set_active() flags the port as deactivating and uses
a GCond to wait until the jack_process_cb() has run once more and cleared the
flag. This way the client zero's the buffer. This happens if one manyally go
to PAUSED and then to READY, while leting the mainloop run inbetween.
Add a new connection mode to jacksrc and jacksink. In this new auto-force
connection mode jack will create as many ports as requested/needed in the
pipeline and will then connect as many physical ports as possible, possibly
leaving some ports unconnected.
Also get rid of some leftover g_print.
Fixes#575284.
Original commit message from CVS:
* ext/jack/gstjackaudiosink.c:
* ext/jack/gstjackaudiosrc.c:
Query port latencies for sink/src delays.
* ext/jack/gstjackbin.c:
No printf please.
