Doesn't really affect logic, but Coverity reports this as dead-code, and
I figure it makes sense to be consistent about our use of HAVE_MEMFD.
CID: 1352045
tests/core-util-test.c uses ck_assert_int_lt() which was introduced
in check 0.9.10
make this dependency (with --enable-tests) explicit in configure.ac
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
on oldish Ubuntu 12.04:
tests/core-util-test.c: In function ‘main’:
tests/core-util-test.c:269:66: error: ‘SIGABRT’ undeclared (first use in this function)
tcase_add_test_raise_signal(tc, modargs_test_replace_fail_1, SIGABRT);
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
With this patch module-bluetooth-policy automatically switch from a2dp profile
to hsp profile if some VOIP application with media.role=phone wants to start
recording audio.
By default a2dp profile is used for listening music, but for VOIP calls is
needed profile with microphone support (hsp). So this patch will switch to
hsp profile if some application want to use microphone (and specify it in
media.role as "phone). After recording is stopped profile is switched back
to a2dp. So this patch allows to use bluetooth microphone for VOIP applications
with media.role=phone automatically without need of user interaction.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
It was a very confusing state variable that required a lot of
fiddling. It was also redundant in that it can be computed from
the other variables, removing any risk of it getting out of sync.
In the same spirit, make sure "requested" also always contains a
sane value, even though it may not be used by every caller.
This involves in particular pa_memblockq_missing() and
pa_memblockq_pop_missing(). The test demonstrates that the latter
doesn't work as expected. It should report whenever queue level is
drained below target level. Instead, it reports any case that the queue
level is drained, even when it is still above target level.
- Set the loglevel once in the main entry code instead of in each test function.
- Check pool allocation succeeded.
- Reduce code by using utility function to allocate chunks.
- Improve coverage by using utility function to validate queue invariants.
In particular, the relations between base, minreq, tlength, length,
missing, maxlength follow certain rules. On change, these invariants can
be violated, which requires additional code to restore them. Setting one
value can thus cause a cascade of changes. This utility function can
assert those invariants after changing something.
Having it handled in the callers proved to be a poor fit as it
became difficult to handle a shrinking minreq sanely. It could end
up in a state where the request was never sent downstream to the
client.
The reason for depending on the socket unit is rather unobvious, so
let's add a comment to help people reading the service unit file. Felipe
Sateler explained the rationale well in the commit message of
7cb524a77b, so I just copied the same text into the comment.
This commit fixes two problems:
1. Because there are no implicit dependencies between sockets and services,
the socket, as set up by systemd will race with the socket, as set up
by the pulseaudio daemon. This can cause the pulseaudio.socket unit to
fail (even though the pulseaudio service started just fine), which can
confuse users.
2. While it is possible to use the service without the socket, it is not
clear why it would be desirable. And a user installing pulseaudio and
doing `systemctl --user start pulseaudio` will not get the socket
started, which might be confusing and problematic if the server is to
be restarted later on, as the client autospawn feature might kick in.
We do support system mode for the cases where it makes sense, so it's
really not sensible to be unconditionally snarky at our users for doing
it.
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
Replace the current latency controller with a modified P-controller. For
better readability separate the controller function. For small latency
differences, the controller forms a classical P-controller while it saturates
at 1% deviation from the base rate for large latency differences.
After switching source or sink, call adjust_rates after a third of a second
instead of waiting one full adjust time. This will ensure that latency regulation
starts as soon as possible.
Restaring the timer and obtaining the latency snapshots belong to the timer callback.
To maintain an adjust time as near as possible to the configured value, the timer is
now restarted immediately at the beginning of the timer callback.
To improve the overall latency estimation, the delay between the two snapshots
is taken into account. To minimize the snapshot delay, the order of the snapshots
is reverted. Additionally the latency at the base rate is calculated. It will be
used later as the input to the latency controller.
The delay and render memblockq are using the source and sink sample specs,
so using pa_bytes_to_usec() will produce better estimates of the delays than
using pa_resmpler_result(). Because the delays are considered to be part of
the sink or source latency, they are added to them. source_output_buffer
becomes obsolete.
The behaviour is to leave the value unchanged. The idea is to init the value
with a default before the call and not treat a missing value as error. That
way, only parsing errors or validating errors actually return error codes.
The alsa card hasn't so far set any availability for profiles. That
caused an issue with some HDMI hardware: the sound card has two HDMI
outputs, but only the second of them is actually usable. The
unavailable port is marked as unavailable and the available port is
marked as available, but this information isn't propagated to the
profile availability. Without profile availability information, the
initial profile policy picks the unavailable one, since it has a
higher priority value.
This patch adds simple logic for marking some profiles unavailable:
if the profile only contains unavailable ports, the profile is
unavailable too. This can be improved in the future so that if a
profile contains sinks or sources that only contain unavailable ports,
the profile should be marked as unavailable. Implementing that
requires adding more information about the sinks and sources to
pa_card_profile, however.
BugLink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8448
I want module-alsa-card to set the availability of unavailable
profiles before the initial card profile gets selected, so that the
selection logic can use correct availability information.
module-alsa-card initializes the jack state after calling
pa_card_new(), however, and the profile selection happens in
pa_card_new(). This patch solves that by moving parts of pa_card_new()
to pa_card_choose_initial_profile() and pa_card_put().
pa_card_choose_initial_profile() applies the profile selection policy,
so module-alsa-card can first call pa_card_new(), then initialize the
jack state, and then call pa_card_choose_initial_profile(). After that
module-alsa-card can still override the profile selection policy, in
case module-alsa-card was loaded with the "profile" argument. Finally,
pa_card_put() finalizes the card creation.
An alternative solution would have been to move the jack
initialization to happen before pa_card_new() and use pa_card_new_data
instead of pa_card in the jack initialization code, but I disliked
that idea (I want to get rid of the "new data" pattern eventually).
The order in which the initial profile policy is applied is reversed
in this patch. Previously the first one to set it won, now the last
one to set it wins. I think this is better, because if you have N
parties that want to set the profile, we avoid checking N times
whether someone else has already set the profile.
There is currently no use for allowing modules to cancel card creation,
and I don't see need for that in the future either. Let's simplify
things by removing the failure handling code.
This allows us to parse an extra set of modargs to tack on to an
existing set. Duplicates in the second set are ignored, since this fits
our use best. In the future, this could be extended to support different
merge modes (ignore dupes vs. replace with dupes), but I've left this
out since there isn't a clear need and it would be dead code for now.
Renamed all variables pertaining to latency offsets of sinks and sources,
calling them "port_latency_offset" or similar instead. All of these variables
refer to latency offsets inherited from ports, rather than being unique to
the sinks or sources themselves.
This change is to pave the way for additional functionality for setting
latency offsets on sources and sinks independenly from the value they inherit
from their port. In order to implement them we first need this rename so that
the two latency offsets can be stored individually and summed when reporting
the total latency of the source or sink.
The renames made are:
pa_sink_set_latency_offset() -> pa_sink_set_port_latency_offset()
pa_source_set_latency_offset() -> pa_source_set_port_latency_offset()
sink->latency_offset -> sink->port_latency_offset
sink->thread_info.latency_offset -> sink->thread_info.port_latency_offset
source->latency_offset -> source->port_latency_offset
source->thread_info.latency_offset -> source->thread_info.port_latency_offset
PA_SINK_MESSAGE_SET_LATENCY_OFFSET -> PA_SINK_MESSAGE_SET_PORT_LATENCY_OFFSET
PA_SOURCE_MESSAGE_SET_LATENCY_OFFSET -> PA_SOURCE_MESSAGE_SET_PORT_LATENCY_OFFSET
Unlike pa_sink_set_port(), which calls pa_sink_set_latency_offset() to update
the latency offset of the sink to match that of its newly set port,
pa_source_set_port() did not do so. This patch adds the appropriate call to
pa_source_set_latency_offset() in pa_source_set_port() to fix this.
