PulseAudio defines PA_RATE_MAX as the maximum sampling rate that it
supports. We were previously exposing a maximum rate of INT_MAX, which
is incorrect, but worked because nothing was really using a rate greater
than 384000 kHz.
While playing DSD data, we hit a case where there might be very high
sample rates (>1MHz), and pulsesink fails during stream creation with
such streams because it erroneously advertises that it supports such
rates.
Since PA_RATE_MAX is #define'd to (8*48000U), we can't just use it in
the caps string. Instead, we fix up the rate to what we actually support
whenever we use our macro caps.
This reverts commit 0dd46accf6.
With some audiosinks, starting the ringbuffer on the first commit
causes audio glitches at startup by starting to output segments
from the ringbuffer before it has been filled / fully prerolled. This
doesn't usually happen with pulsesink because we map the pulseaudio
ringbuffer directly, but we should keep things consistent with
other sinks with regards to startup latency, plus it gives more
headway to avoid glitching, should the initial 2nd segment take
more than 10ms to generate.
https://bugzilla.gnome.org/show_bug.cgi?id=657076
In pulsesink_query function, we use a switch for the query
type. In the CAPS case, there is no 'break', instead we
return right away. Use a break and return at the end of
the function instead for better code readability.
https://bugzilla.gnome.org/show_bug.cgi?id=744461
If we can not create probe stream in query_getcaps function, it will appear
memory leakage from format info.
The following patch prevent memory leakage in pulsesink.
https://bugzilla.gnome.org/show_bug.cgi?id=743178
We need a mechanism in PulseAudio to allow running code outside the
mainloop lock. Then we'd be able to post to the bus (taking the
GST_OBJECT_LOCK), without worrying about locking order with the mainloop
lock, which is the current cause of deadlocks while trying to post the
stream status messages.
https://bugzilla.gnome.org/show_bug.cgi?id=736071
This gives a quick introduction to how the pulsesink/pulsesrc code
interacts with the pa_threaded_mainloop that we start up to communicate
with the server.
The stream status messages are emitted in the PA mainloop thread, which
means the mainloop lock is taken, followed by the Gst object lock (by
gst_element_post_message()). In all other locations, the order of
locking is reversed (this is unavoidable in a bunch of cases where the
object lock is taken by GstBaseSink or GstAudioBaseSink, and then we get
control to take the mainloop lock).
The only way to guarantee that the defer callback for stream status
messages doesn't deadlock is to either stop posting those messages, or
make sure that the message emission is completed before we proceed to
any point that might take the object lock before the mainloop lock
(which is what we do after this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=736071
This reverts commit 01457027e0.
We'll just depend on PulseAudio 2.0 or above instead of having the bug
partially fixed based on the installed libpulse version.
The getcaps function we added uses some pa_format_info_get_prop...
accessor functions that were only added in 2.0, so we only have our
getcaps implementation exist if we're compiling against libpulse 2.0 or
above.
Eventually, we could bump the minimum requirement to 2.0 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=686459
getcaps is called frequently during stream setup, and creating a new
stream each time is very inefficient. There's some more room for
optimisation by caching the queried sink formats as well, but this needs
some more changes to listen for format changes on the sink (for when
supported formats change between probe stream creation and sink
querying).
https://bugzilla.gnome.org/show_bug.cgi?id=686459
This allows us to have more fine-tuned caps in READY or above. However,
this is _really_ inefficient since we create a new stream and query sink
for every getcaps in READY, which on a simple gst-launch line happens
about 35 times. The next step is to cache getcaps results.
https://bugzilla.gnome.org/show_bug.cgi?id=686459
This makes sure that we update segdone based on the read index received
during latency updates. As the comment notes, we make some compromises
to deal with the fact that segdone is a segment multiple, while the read
index offers finer granularity. The updates are also not very often
(100ms since that is how often automatic timing updates are provided).
All this is required for the baseaudiosink sample alignment code to work
at all.
https://bugzilla.gnome.org/show_bug.cgi?id=694257
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
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.
