The code in the "io_fail" section was only used for HUP handling, but
there were jumps to there also from places where reading or writing
failed, because the read/write failure could have been caused by HUP.
This patch simplifies things by checking for HUP condition before
trying to read or write. Now if reading or writing fails, we will
jump to "fail" directly instead of going via the "io_fail" label. As
a result, the "io_fail" label isn't needed any more.
Previously relative cookie paths were searched from the home
directory, now they are searched from the config home directory. This
fixes the problem that XDG_CONFIG_HOME didn't have effect on cookie
paths.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=75006
If a relative path is passed to pa_authkey_load(), it will interpret
the path as relative to the home directory. This is wrong, because
relative paths should be interpreted to be relative to the config home
directory. Before fixing pa_authkey_load(), this patch prepares for
the change by using absolute paths when the file actually needs to be
in the home directory (i.e. the fallback cookie path for the native
protocol and the default cookie path for the esound protocol).
The only place where pa_authkey_load() was called was in
pa_authkey_load_auto(), and the only functionality that
pa_authkey_load() was to log a warning if load() fails. That log
message is now in pa_authkey_load_auto(), so pa_authkey_load() has no
use any more.
pa_context already ignored the return value of pa_client_conf_load(),
so the only places where the return value was not ignored were the
D-Bus server lookup thing and pax11publish. I don't think those cases
are negatively affected if they ignore errors in opening or parsing
client.conf.
pa_client_conf_env() never failed anyway, so returning int was
obviously redundant.
block_usec should be determined by the sink max latency, not the other
way around. This change doesn't cause any change in behaviour, but
makes the code more logical. Further updates to block_usec are already
done correctly, so this is the only place that needs modification.
Mark the sink as DYNAMIC_LATENCY and implement update_sink_latency_range
on its sink-input to collect the combined latency range of all sinks.
Implement update_requested_latency on the sink to configure the final
latency by combining the sink-input requested latencies. This makes us
honour the client latency request.
Also add more debug log.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=47899
- Make sure "no evacuation sink/source found" is not printed when
fallback source/sink is selected
- Restore previous behaviour of fallback sink/source selected
(first one instead of last one)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Recently met a problem: when I disconnect the bluetooth headset, the
pulseaudio automatically switch the sound to sink of HDMI output
instead of the sink of internal speaker even though there is no HDMI
cable connected.
To fix this problem, I want to change the rule of selecting the target
sink if the default sink is not available. (same rules apply to the
source selecting):
construct a new hashmap with all ports (of all relevant sinks) and
then call find_best on the new hashmap to find the best port, finally
find the corresponding sink using the best port.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Having an extra variable that tracks the wakeup status introduces a
race where the variable is set but the data has yet to propagate from
the write end of the pipe to the read end. When this happens the
system goes into a tight loop as select() always returns immediately.
There are several intertwined changes that I couldn't separate into
nicer commits. This is mostly just refactoring, but this also fixes
a bug: the old code set the device valid in parse_device_properties()
even if the device's adapter was invalid (had NULL address).
To improve the clarity of the code, I split the device_info_valid
variable into two booleans: properties_received and valid.
I added function device_update_valid() that checks all conditions that
affect the device validity. The function can then be called from any
place where something changes that potentially affects the device
validity. However, currently the only validity-affecting thing that
can change is the device adapter, so device_update_valid() is only
called from set_device_adapter().
I added the aforementioned set_device_adapter() function so that
whenever the adapter is set, the device validity gets updated
automatically.
The new properties_received variable allowed me to remove the
is_property_update function parameters.
This is a cosmetic change. There are a couple of places where we check
whether the adapter object is valid, and while checking whether the
address property is set works just fine, I find it nicer to have a
dedicated flag for the object validity. This improves maintainability
too, because if there will ever be more adapter properties that affect
the adapter validity, the places that check if the adapter is valid
don't need to be updated.
On FIONREAD returning 0 bytes, we cannot return success, as the caller
(rtpoll_work_cb in module-rtp-recv.c) would then try to
pa_memblock_unref(chunk.memblock) and, because memblock is NULL, trigger
an assertion.
Also we have to read out the possible empty packet from the socket, so
that the kernel doesn't tell us again and again about it.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
This fixes assertion failures that manifest themselves with cards that
support only weird rates such as 37286Hz. Tested with snd-pcsp.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=48109
Add the output from its sink-input attached callback and remove it
again from the detach callback. This simplifies some output_enable
and we can also avoid posting 2 messages for the sink.
Surround 2.1 is one of the more common surround profiles these days,
so it's about time we support it.
The "surround21" was added to alsa-lib a few months ago, and there
hasn't yet been an alsa-lib release since, but I doubt it will change.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This name is more acurate with regards of what role we're currently
playing and we've already been using it in
pa_bluetooth_profile_to_string() since 449d6cb.
As it is implemented, the early request mode can in some cases be counter-productive. The mode is designed to give the client a steady request/report rate of small-ish chunks (A somewhat silly client requirement but at least Flash and Firefox break horribly when you break this.).
Unfortunately PulseAudio does not have any mechanism for telling a sink/source how often it should request/report data. So a more blunt hack was applied where the entire latency is restricted to the fragment size.
So far so good, but where the current code breaks down is when the sink cannot satisfy this tiny latency request. We then "report" to the client what we can guarantee by setting the fragment size to the sink's/source's full buffer size/latency.
This severely changes the resulting buffer attributes from what the client requested, and in practice breaks applications. The most prominent user of this feature is the ALSA plugin, and it doesn't even have a mechanism of adapting to the server giving back something different than what was requested.
So long term, the whole early request mode needs to be implemented in a better way. Either the sink's/source's need to grow the ability to control request/report rate. Or we put some form of timer based emulation in front of them on behalf of these clients.
Short term, we should change the behaviour of what happens when we cannot guarantee a fragment rate. Instead of giving the client really shitty buffering parameters as a result, we should just keep the requested attributes and do things on a best-effort basic. Basically how things would behave if the client didn't have the early request bit at all.
The attached patch does just that, as well as expand on the comment about how the early request thing is implemented.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=66962
speex_resample_float() does not work with speex compiled with
--enable-fixed-point, because speex expects its float input
to be normalized to ±32768 instead of the more usual ±1.
It is possible to fix speex_resample_float(), as demonstrated at
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-May/020617.html
However, a better idea is to avoid using the speex-float resampler and
the associated s16 <-> float conversions that speex will immediately undo
internally if it is known that speex has been compiled with FIXED_POINT.
So, transparently change speex-float-* to speex-fixed-* in that case.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Reported-by: Fahad Arslan <fahad_arslan@mentor.com>
Cc: Damir Jelić <poljarinho@gmail.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
FIXED_POINT detection is based on code by Peter Meerwald.
The warnings were produced because the command-line flag redefined the
value of _FORTIFY_SOURCE coming from the specs on some distributions,
including Gentoo. So, undefine this macro before defining it.
