Coverity complained about data->sink being possibly NULL when it's
dereferenced later. It was difficult for me to figure out whether that
was a false positive or not. Hopefully the comments make it a bit
easier to reason about the code in the future.
CID: 1323591
This rejigs the update_rate() logic to encompass changes to the sample
spec as a whole, as well as passthrough status. As a result,
sinks/sources provide a reconfigure() method which allows
reconfiguration as required.
The behaviour itself is currently unchanged -- alsa-sink/-source do not
actually implement anything other than rate updates for now (nor are
they ever requested to). This can be modified in the future, to allow,
for example 24-bit output when incoming media supports it, as well as
channel count changes for passthrough sinks.
Another related change is that passthrough status is now part of
sink/source reconfiguration, and we can stop doing a suspend/unsuspend
when entering/leaving passthrough state. So that part is now divided
in two -- pa_sink_reconfigure() sets the sink in passthrough mode if
required, and pa_sink_enter_passthrough() sets up everything else
(this currently means only volumes, but could disable other processing)
for passthrough mode.
the comment /* Fall through. */ fixes the warning, but gcc-7 seems to be more
picky about the position in the code
pulsecore/sink-input.c: In function ‘pa_sink_input_update_proplist’:
pulsecore/sink-input.c:1531:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
for (state = NULL; (key = pa_proplist_iterate(i->proplist, &state));) {
^~~
pulsecore/sink-input.c:1539:9: note: here
case PA_UPDATE_REPLACE: {
^~~~
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
When a filter sink is moving, it's not connected to any master sink, and
therefore it's not connected to any IO thread either. In this situation
trying to move a stream that is connected to the filter sink is likely
to result in crashing, because starting the move involves sending a
message to the IO thread. Sometimes this works by accident (the
asyncmsgq of the filter sink still points to the old master sink's
asyncmsgq), but we really should never attempt it. This patch blocks all
moves where the moving stream is connected to a filter sink that itself
is in the middle of a move.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100277
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
If pa_sink_input_cork() or pa_source_output_cork() were called without a sink
or source attached, the calls would crash pulseaudio.
This patch fixes the problem, so that a source output or sink input can still
be corked or uncorked while source or sink are invalid. This is needed to
correct the corking logic in module-loopback.
At the time the "unlink post" hook is fired, the stream is not any more
connected to its old device, so it makes sense to reset the sink/source
pointer to NULL before firing the hook. If this is not done, the pointer
may become stale during the "unlink post" hook, because
module-bluetooth-policy does a card profile change in its "unlink post"
callback, so even if the pointer is valid when module-bluetooth-policy's
callback is called, it will be invalid in subsequent callbacks.
Sink(-input) and source(-output) called unlink function when reference
count dropped to zero. This would result in unlink hooks being called
with an object having a reference count of zero, and this is not a
situation we want modules to have to deal with. It is better to just
remove the redundant unlinking code from sink(-input) and
source(-output) and assert on reference count in unlink functions as well.
It is expected that in well behaving code the owner of an object will
always unlink the object before unreferencing.
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
pa_sink_input_update_proplist() is inconvenient in many cases, because
it requires allocating a new proplist, even if the goal is to just set
one property. pa_sink_input_update_properties also can't properly log
property changes, because it has to assume that all values are
arbitrary binary data.
This patch adds pa_sink_input_set_property() for setting a string
value for a single property, and pa_sink_input_set_property_arbitrary()
for setting a binary value for a single property.
pa_sink_input_update_properties() is reimplemented as a wrapper around
pa_sink_input_set_property_arbitrary() to centralize logging and
sending change notifications.
(The above mentions only sink input functions for brevity, but the
same changes are implemented for source outputs too.)
Before a device is unlinked, the unlink hook is fired, and it's
possible that a routing module tries to move streams to the unlinked
device in that hook, because it doesn't know that the device is being
unlinked. Of course, the unlinking is obvious when the code is in an
unlink hook callback, but it's possible that some other module does
something in the unlink hook that in turn triggers some other hook,
and it's this second hook where the routing module may get confused.
This patch adds an "unlink_requested" flag that is set before the
unlink hook is fired, and moving streams to a device with that flag
set is prevented.
This patch is motivated by seeing module-device-manager moving a
stream to a sink that was being unlinked. It was a complex case where
an alsa card was changing its profile, while an echo-cancel sink was
connected to the old alsa sink. module-always-sink loaded a null sink
in the middle of the profile change, and after a stream had been
rescued to the null sink, module-device-manager decided to move it
back to the old alsa sink that was being unlinked. That move made no
sense, so I came up with this patch.
This gets rid of an error message from the debug log. If
volume_factor_source would actually be used somewhere, this bug would
have caused more severe problems.
volume_factor_source should have the source's channel map. When moving
the stream, the volume needs to be remapped from the old source's
channel map to the new source's map. However, when the stream is being
moved, there is a period where the old source has already been
forgotten and the new source isn't yet known, so the remapping can't
be done directly between the two channel maps. Instead, the volume is
remapped from the old source's map to the stream's own map when the
move starts, and again remapped from the stream's map to the new
source's map when the move finishes.
The first remapping was missing, causing the second remapping fail and
print an error to the log.
(I checked the sink input code as well. It didn't have this bug.)
Applying the volume after resampling means mismatch between the volume
channel map and the data channel map.
volume_factor_source is not currently used anywhere, so this bug
hasn't been causing any problems. I noticed it while reading the code.
The resampler framework just forwards the request to the lfe filter.
There are no resampler impl that can rewind yet, so just reset the
resampler impl instead of properly rewinding yet.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Add a user defined parameter lfe-crossover-freq for the lfe-filter,
to pass this parameter to the lfe-filter, we need to change the
pa_resampler_new() API as well.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
supresses a warning when compiling with NDEBUG:
pulsecore/aupdate.c: In function 'pa_aupdate_read_end':
pulsecore/aupdate.c:82:14: warning: variable 'n' set but not used [-Wunused-but-set-variable]
unsigned n;
pulsecore/sink-input.c: In function 'pa_sink_input_unlink':
pulsecore/sink-input.c:648:27: warning: variable 'p' set but not used [-Wunused-but-set-variable]
pa_source_output *o, *p = NULL;
pulsecore/sink-input.c: In function 'find_filter_sink_input':
pulsecore/sink-input.c:1523:14: warning: unused variable 'i' [-Wunused-variable]
unsigned i = 0;
pulsecore/sink-input.c: In function 'pa_sink_input_start_move':
pulsecore/sink-input.c:1569:27: warning: variable 'p' set but not used [-Wunused-but-set-variable]
pa_source_output *o, *p = NULL;
CC pulsecore/libpulsecore_5.0_la-sink.lo
pulsecore/sink.c: In function 'pa_sink_unlink':
pulsecore/sink.c:673:24: warning: variable 'j' set but not used [-Wunused-but-set-variable]
pa_sink_input *i, *j = NULL;
pulsecore/source-output.c: In function 'find_filter_source_output':
pulsecore/source-output.c:1179:9: warning: unused variable 'i' [-Wunused-variable]
int i = 0;
CC pulsecore/libpulsecore_5.0_la-source.lo
pulsecore/source.c: In function 'pa_source_unlink':
pulsecore/source.c:616:27: warning: variable 'j' set but not used [-Wunused-but-set-variable]
pa_source_output *o, *j = NULL;
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This makes it easy to log a message every time the reference ratio
changes. I also need to add a hook for reference ratio changes, but
that need will go away if the stream relative volume controls will be
created by the core in the future.
Forcing all volume changes to go through set_volume_direct() makes
it easier to check where the stream volume is changed, and it also
allows us to have only one place where notifications for changed
volume are sent.
Forcing all reference volume changes to go through
set_reference_volume_direct() makes it easier to check where the
reference volume is changed, and it also allows us to have only one
place where notifications for changed reference volume are sent.
"i->save_muted = i->save_muted || mute" makes no sense. The intention
was most likely to use "save" instead of "mute" in the assignment.
This line originates from reverting the volume ramping code, commit
8401572fd5.
The idea of "i->save_muted |= save" is that even if the mute state
doesn't change, save_muted should still be updated, but only if the
transition is from "don't save" to "save".
Changing "!i->muted == !mute" to "mute == i->muted" is cosmetic only.
The rationale behind the old form was probably that when we still had
pa_bool_t, booleans could in theory be defined as int, so comparing
the values without the ! operator was not entirely safe. That's
unnecessary now that we use the standard bool type, which can only
have values 0 or 1.
Steps to reproduce:
1) Leave LFE remixing disabled (the default)
2) Start playback of stereo material on e g 5.1 surround, notice nothing in LFE
3) Now change profile to e g 4.0 surround and then back to 5.1 surround
4) Notice that LFE channel is now remixed
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
A segfault was reported on this line:
pa_return_val_if_fail(PA_SINK_IS_LINKED(pa_sink_get_state(data->sink)), -PA_ERR_BADSTATE);
After expanding the pa_sink_get_state() macro, the line looks like
this:
pa_return_val_if_fail(PA_SINK_IS_LINKED(data->sink->state), -PA_ERR_BADSTATE);
So data->sink was apparently NULL. That could happen if we try to fall
back to the default sink, but format negotiation fails.
This bug was introduced in commit
71816ecb7f.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=74646
The "fix flags" (PA_SINK_INPUT_FIX_FORMAT etc.) don't work properly
with the pa_stream_new_extended() interface. This patch fixes it so
that the same effect can be achieved by leaving some of the PCM
parameters unspecified in format info objects. Also, when converting
a sample spec to a format info when using the old pa_stream_new()
interface, the "fix flags" are taken into account in that conversion.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=68952
It's bad form to assume in free() that any member of the struct has
been initialized. I ran into problems with this when I reordered
things in pa_sink_input_new() and pa_source_output_new().
If a capture stream captures from a single sink input (so the capture
stream is a so called "direct on input" stream), then it needs to
connect to the monitor source of the sink to which the sink input is
connected. Previously the correct source was not figured out
automatically, causing the capture stream creation to fail.
This patch replaces every occurrence of '){' with ') {'.
The ffmpeg source tree was excluded since it will disappear anyways.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-exec sed -i -e 's/){/) {/' {} \;
This fixes a later assertion failure in module-stream-restore.
Buglink: https://bugs.launchpad.net/bugs/896602
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
idea is to allow optimized code path (similar to volume code)
and rework/specialize mixing cases to enable runtime performance improvements
no functionality changes in this patch
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This makes sure we don't try to plug in a passthrough stream if the
final sink/source sample spec doesn't match what we want. In the future,
we might want to change rate updates to try a full sample spec update
for passthrough streams.
https://bugs.freedesktop.org/show_bug.cgi?id=50951
