When a source is unlinked, all streams of this source are moved to
default_source, this action is implemented in the core rather than
modules now.
And after this change, the module-rescue-streams is not needed, but
for backward compatibility, we keep it as a dummy module.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
When a new source appears, all streams that have their
preferred_source set to the new source should be moved to the new
source.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
When the default source changes, the streams from the old default
source should be moved to the new default source, unless the
preferred_source string is set to the old default source and the
active port of the old default source is not unavailable
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Currently, virtual sinks and sources are not suspended when the master sink
or source is suspended. To implement this, the slave must be able to track
the suspend cause of the master.
With this patch, the sink input suspend callback will not only be called
when the sink or source is changing state, but also when the suspend cause
changes. Similar to the set_state_in_*_thread_cb() functions, the suspend
callback receives a state and a suspend cause as additional arguments.
Because the new state and suspend cause of the sink or source have already
been set, the old values are passed to the callback.
Sample format(e.g. 16 bit, 24 bit) was not considered even if the
avoid-resampling option is set or the passthrough mode is used.
This patch checks both sample format and rate of a stream to
determine whether to avoid resampling in case of the option is set.
In other word, it is possble to use the stream's original sample
format and rate without resampling as long as these are supported
by the device.
pa_sink_input_update_rate() and pa_source_output_update_rate() are
renamed to pa_sink_input_update_resampler() and pa_source_output
_update_resampler() respectively.
functions are added as below.
pa_sink_set_sample_format(), pa_sink_set_sample_rate(),
pa_source_set_sample_format(), pa_source_set_sample_rate()
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
pa_sink_get_state() and pa_source_get_state() just return the state
variable. We can as well access the state variable directly.
There are no behaviour changes, except that module-virtual-source
accessed the main thread's sink state variable from its push() callback.
I fixed the module so that it uses the thread_info.state variable
instead. Also, the compiler started to complain about comparing a sink
state variable to a source state enum value in protocol-esound.c. The
underlying bug was that a source pointer was assigned to a variable
whose type was a sink pointer (somehow using the pa_source_get_state()
macro confused the compiler enough so that it didn't complain before).
I fixed the variable type.
pa_sink_input_get_state() and pa_source_output_get_state() just return
the state variable. We can as well access the state variable directly.
There are no behaviour changes, except that some filter sources accessed
the main thread's state variable from their push() callbacks. I fixed
them so that they use the thread_info.state variable instead.
Previously, the "avoid-resampling" option of daemon.conf is to make the
daemon try to use the stream sample rate if possible for all sinks or
sources.
This patch applies this option to module-udev-detect and module-alsa-card
as a module argument in order to override the default value of daemon.conf.
As a result, user can use this argument for more fine-grained control.
e.g.) set it false in daemon.conf and set it true for module-udev-detect
or a particular module-alsa-card in default.pa.(or vice versa)
To set it, use "avoid_resampling=true or false" as the module argument.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
Reconfiguration callback should also be set in case of avoiding resampling
option. This patch set the callback for every case because the callback
has already conditions to leave if it is not needed.
Also unnecessary codes of setting alternate sample rate to 0 are removed.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
The alsa sink calls pa_sink_suspend() from the set_port() callback.
pa_sink_suspend() can only be called from the main thread, but the
set_port() callback was often called from the IO thread. That caused an
assertion to be hit in pa_sink_suspend() when switching ports.
Another issue was that pa_sink_suspend() called the set_port() callback,
and if the callback calls pa_sink_suspend() again recursively, nothing
good can be expected from that, so the thread mismatch was not the only
problem.
This patch moves the mixer syncing logic out of pa_sink/source_suspend()
to be handled internally by the alsa sink/source. This removes the
recursive pa_sink_suspend() call. This also removes the need to have the
mixer_dirty flag in pa_sink/source, so the flag and the
pa_sink/source_set_mixer_dirty() functions can be removed.
This patch also changes the threading rules of set_port(). Previously it
was called sometimes from the main thread and sometimes from the IO
thread. Now it's always called from the main thread. When deferred
volumes are used, the alsa sink and source still have to update the
mixer from the IO thread when switching ports, but the thread
synchronization is now handled internally by the alsa sink and source.
The SET_PORT messages are not needed any more and can be removed.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104761
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
There are no behaviour changes, the code from almost all the SET_STATE
handlers is moved with minimal changes to the newly introduced
set_state_in_io_thread() callback. The only exception is module-tunnel,
which has to call pa_sink_render() after pa_sink.thread_info.state has
been updated. The set_state_in_io_thread() callback is called before
updating that variable, so moving the SET_STATE handler code to the
callback isn't possible.
The purpose of this change is to make it easier to get state change
handling right in modules. Hooking to the SET_STATE messages in modules
required care in calling pa_sink/source_process_msg() at the right time
(or not calling it at all, as was the case on resume failures), and
there were a few bugs (fixed before this patch). Now the core takes care
of ordering things correctly.
Another motivation for this change is that there was some talk about
adding a suspend_cause variable to pa_sink/source.thread_info. The
variable would be updated in the core SET_STATE handler, but that would
not work with the old design, because in case of resume failures modules
didn't call the core message handler.
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
This adds a pa_suspend_cause_t parameter to the sink/source_set_state()
functions, and moves part of the work that pa_sink/source_suspend() does
to sink/source_set_state(). The reason for this code shuffling is that I
plan to make all suspend cause changes available to modules through the
state change callbacks. This is the first step towards that.
Additionally, pa_source_sync_suspend() is changed to also update the
suspend cause of the monitor source when the suspend cause of the
monitored sink changes. That probably doesn't have much effect on
anything, but I think it makes sense to mirror the sink suspend cause in
the monitor source.
pa_source_sync_suspend() has also a bug fix: previously it was probably
possible that a sink might get suspended while in the passthrough mode.
When the sink then resumed (while still in the passthrough mode),
pa_source_sync_suspend() would resume also the monitor source, even
though the monitor source should be kept suspended when the sink is in
the passthrough mode. Now the monitor source won't be resumed in this
situation.
Previously the suspend cause was logged as a hexadecimal number, now
it's logged as a human-friendly string.
Also, the command line interface handled only a subset of causes when
printing them, now all suspend causes are printed.
When a sink input was unlinked between the calls to pa_sink_move_all_start() and
pa_sink_move_all_finish(), pa_sink_move_all_finish() tried to finish the move
of the already unlinked sink input, which lead to an assertion in
pa_sink_input_finish_move(). The same applies for the source side.
This patch fixes the problem by checking the state of the sink input or
source output in pa_*_move_all_finish().
Bug report: https://bugs.freedesktop.org/show_bug.cgi?id=103752
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 order of the pa_sink_input_put() and pa_sink_put() calls in filter
modules was swapped in commit edc465da77 ("virtual sources and sinks:
Don't double attach a sink input or source output on filter load").
If flat volumes and volume sharing is enabled, the pa_sink_input_put()
call will update volumes of the whole tree of virtual sinks that are
connected to the root sink. The recursive updating procedure tried to
also update the volume of the new sink for which pa_sink_put() had not
yet been called, causing an assertion failure.
This patch tries to make sure that the volume of not-yet-linked sinks
is never changed. pa_sink_put() will set the sink volume correctly, so
it's fine to skip the not-yet-linked sinks during pa_sink_input_put().
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102549
This allows us to restore the default device properly when a
hotpluggable device (e.g. a USB sound card) is set as the default, but
unplugged temporarily. Previously we would forget that the unplugged
device was ever set as the default, because we had to set
configured_default_sink to NULL to avoid having a stale pa_sink pointer,
and also because module-default-device-restore couldn't resolve the name
of a currently-unplugged device to a pa_sink pointer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89934
In sink_put() and source_put(), pa_core_update_default_{sink,source}() was called
before the PA_CORE_HOOK_{SINK,SOURCE}_PUT hook. Therefore module-switch-on-connect
could not correctly determine the old default sink/source if no user default was
set and a sink/source with higher priority than any other sink/source turned up.
This patch corrects the problem by swapping the order of the hook call and the
pa_core_update_default_sink() call.
Additionally it corrects a problem in module-switch-on-connect. If, after the
change above, the new sink/source was the first sink/source to appear, pulseaudio
would crash because module-switch-on-connect assumed that the default sink/source
was not NULL. The patch checks if the default sink/source is NULL and only sets
the new default sink/source in that case.
When sinks are compared during the default sink selection, the active
port's availability is inspected. Therefore, the default sink should be
updated when the active port changes, because the new port may have
different availability status than the old port.
For example, let's say that a laptop has an analog sink with a speaker
and a headphone port, and headphones are initially plugged in, so both
ports can be used[1]. The headphone port is initially the active port.
There's also a null sink in the system. When the headphones are
unplugged, the headphone port becomes unavailable, and the null sink
becomes the new default sink. Then module-switch-on-port-available
changes the analog sink port to speakers. Now the default sink should
change back to the analog sink, but that doesn't happen without this
patch.
[1] Actually we currently mark speakers as unavailable when headphones
are plugged in, but that's not strictly necessary. My example relies on
both ports being available initially, so the bug can't be reproduced
with the current mixer configuration.
Currently the default sink policy is simple: either the user has
configured it explicitly, in which case we always use that as the
default, or we pick the sink with the highest priority. The sink
priorities are currently static, so there's no need to worry about
updating the default sink when sink priorities change.
I intend to make things a bit more complex: if the active port of a sink
is unavailable, the sink should not be the default sink, and I also want
to make sink priorities dependent on the active port, so changing the
port should cause re-evaluation of which sink to choose as the default.
Currently the default sink choice is done only when someone calls
pa_namereg_get_default_sink(), and change notifications are only sent
when a sink is created or destroyed. That makes it hard to add new rules
to the default sink selection policy.
This patch moves the default sink selection to
pa_core_update_default_sink(), which is called whenever something
happens that can affect the default sink choice. That function needs to
know the previous choice in order to send change notifications as
appropriate, but previously pa_core.default_sink was only set when the
user had configured it explicitly. Now pa_core.default_sink is always
set (unless there are no sinks at all), so pa_core_update_default_sink()
can use that to get the previous choice. The user configuration is saved
in a new variable, pa_core.configured_default_sink.
pa_namereg_get_default_sink() is now unnecessary, because
pa_core.default_sink can be used directly to get the
currently-considered-best sink. pa_namereg_set_default_sink() is
replaced by pa_core_set_configured_default_sink().
I haven't confirmed it, but I expect that this patch will fix problems
in the D-Bus protocol related to default sink handling. The D-Bus
protocol used to get confused when the current default sink gets
removed. It would incorrectly think that if there's no explicitly
configured default sink, then there's no default sink at all. Even
worse, when the D-Bus thinks that there's no default sink, it concludes
that there are no sinks at all, which made it impossible to configure
the default sink via the D-Bus interface. Now that pa_core.default_sink
is always set, except when there really aren't any sinks, the D-Bus
protocol should behave correctly.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=99425
In pa_{source,sink}_new() and pa_{source,sink}_put() the current hardware
volume was miscalculated:
hw volume (dB) = real volume (dB) + soft volume (dB)
was used instead of
hw volume (dB) = real volume (dB) - soft volume (dB)
This lead to a crash in pa_alsa_path_set_volume() if high volumes were
set and the port was changed.
This patch fixes the calculation. Thanks to Tanu for pointing out
the correct solution.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=65520
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.
The previous patch assumed constant port latency offsets. The offsets can
however be changed by the user, therefore these changes need to be tracked
as well. This patch adds the necessary hooks.
Also the print_msg argument was removed from update_minimum_latency() and
update_latency_boundaries() because the message should always be logged.
This serves to explicitly document the various cases we deal with in
pa_sink_update_rate()/pa_source_update_rate() rather than have some of
them hidden behind the initialisation of desired_rate.
This adds an "avoid-resampling" option to daemon.conf that makes the
daemon try to use the stream sample rate if possible (the device needs
to support it, which currently only ALSA does), and there should not be
any other stream connected).
This should enable some of the "audiophile" use-cases where users wish
to play high sample rate audio files without resampling.
We still will do conversion if sample formats don't match, though. This
means that if you want to play 96 kHz/24 bit audio without any
modification the default format will need to be set to be 24-bit as
well. This will force all streams to be upconverted, which, other than
the wasted resources, should be relatively harmless.
Streams are detached when they are removed or moved away from a device,
or when a filter device that they're connected to is removed or moved.
If these cases overlap, a crash will happen due to "double-detaching".
This can happen if a filter sink is removed, and a stream connected to
that filter sink removes itself when its sink goes away.
Here are the steps in more detail: When a filter sink is unloaded, first
it will unlink its own sink input. This will cause the filter sink's
input to be detached. The filter sink propagates the detachment to all
inputs connected to it using pa_sink_detach_within_thread(). After the
filter sink is done unlinking its own sink input, it will unlink the
sink. This will cause at least module-combine-sink to remove its sink
input if it had one connected to the removed filter sink. When the
combine sink removes its sink input, that input will get detached again,
and a crash follows.
We can relax the assertions a bit, and skip the detach() call if the
sink input is already detached.
I think a better fix would be to unlink the sink before the sink input
when unloading a filter sink - that way we could avoid the
double-detaching - but that would be a much more complicated change. I
decided to go with this simple fix for now.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98617
The functions that call attach()/detach() for all streams on a sink or
source didn't update the "attached" flag accordingly. Since the flag is
only used in assertions, this omission didn't cause any harm in normal
use.
The "attached" flag is only used for asserting that the stream is in the
expected state when attaching or detaching.
Sometimes the flag was checked and updated before calling the attach or
detach callback, and sometimes after. I think it makes more sense to
always check it before calling the callback.
In the "unlink post" hook it's not guaranteed that the stream's old
device exists any more, so let's use the "unlink" hook that is safer.
For example, module-bluetooth-policy does a card profile change in the
source-output "unlink post" hook, which invalidates the source-output's
source pointer.
When the "unlink" hook is fired, the stream is still linked to its
device, which affects the return values of the check_suspend()
functions. The unlinked streams should be ignored by the check_suspend()
functions, so I had to add extra parameters to those functions.
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.
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>
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.
Without this, we hit an assert because the channel count in
new_reference (which was inherited from the master) is lower than the
channel count of the filter.
pulsecore/sink.c: In function 'pa_sink_put':
pulsecore/sink.c:648:53: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
pa_assert(!(s->flags & PA_SINK_DYNAMIC_LATENCY) == (s->thread_info.fixed_latency != 0));
^
pulsecore/source.c: In function 'pa_source_put':
pulsecore/source.c:599:55: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
pa_assert(!(s->flags & PA_SOURCE_DYNAMIC_LATENCY) == (s->thread_info.fixed_latency != 0));
^
rewrite expression to suppress warning:
!(x & MASK) == (y != 0)
<->
!(x & MASK) == !(y == 0)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
When a sink or source is freed, there may be pending volume changes that
didn't get applied before the IO thread got torn down. Those pending
changes need to be freed.
The memory leak was reported here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23162/focus=23169
Reported-by: Alexander E. Patrakov <patrakov@gmail.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>
