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 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 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.
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
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.
The relationship between sinks, sources, cards, profiles, and ports
is becoming ever more intertwined, to the point that if you try to
include one file from the other, you're likely to end up with some
weird error somewhere else.
Work around this by creating a new typedefs.h, which does not depend
on anything else, and just creates a few typedefs.
(Can be expanded with more typedefs in the future if the need arises.)
Signed-off-by: David Henningsson <david.henningsson@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.
Forcing all mute changes to go through set_mute() makes it easier to
check where the muted field is changed, and it also allows us to have
only one place where notifications for changed mute are sent.
This refactoring reduces duplication, as mute_changed() used to do the
same things as set_mute(). Other benefits are improved logging
(set_mute() logs the mute change, mute_changed() used to not do that)
and the soft mute state is kept up to date, because set_mute() sends
the SET_MUTE message to the IO thread.
The set_mute_in_progress flag is an extra precaution for preventing
recursion in case a sink/source implementation's set_mute() callback
causes mute_changed() to be called. Currently there are no such
implementations, but I think that would be a valid thing to do, so
some day there might be such implementation.
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.
The latency offset type should be signed (int64_t) so we can also add
a negative latency offset.
This also includes changing the type of the sink/source
offsets and updating pacmd so it handles negative numbers.
A latency offset variable was added to the sink/source struct.
Also a function was introduced to update the latency offset of the
sink/source and a new message type was introduced so we can send the latency
offset to the IO thread.
The latency offset is automatically populated with the latency from the
currently active port.
State which thread calls set_port in which scenario.
Reported-by: Jyri Sasha <oku@iki.fi>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Log in as user A, fast user switch to user B, let user B change
port, volume or mute status, then switch back to user A.
At this point we must make sure that the ALSA and PA volumes are
synchronised by writing to the ALSA mixer when the ALSA device
becomes available.
BugLink: https://bugs.launchpad.net/bugs/915035
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Since both cards and sinks can hold references to a port, it makes
sense to reference count them. Although no current implementation
actually has sinks with ports but without a card, it felt wrong
to make it harder to make such an implementation in the future.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Basically adds code to handle passthrough sources. This isn't a tested
path at the moment, but in the future, when we do wish to support these,
it'll save us the trouble of having to sync all the code again.
Avoid resampling or use integer resampling when supported by the
sinks/sources
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This makes sure that when we're traversing the device chain for sources
and sinks with shared volume, we handle the case that a sink-input or
source-output of one of these might be unlinked (while unloading a
module, for example).
This just covers Lennart's concern over the terminology used.
The majority of this change is simply the following command:
grep -rli sync[-_]volume . | xargs sed -i 's/sync_volume/deferred_volume/g;s/PA_SINK_SYNC_VOLUME/PA_SINK_DEFERRED_VOLUME/g;s/PA_SOURCE_SYNC_VOLUME/PA_SOURCE_DEFERRED_VOLUME/g;s/sync-volume/deferred-volume/g'
Some minor tweaks were added on top to tidy up formatting and
a couple of phrases were clarified too.
This is not currently useful but future commits will make further
changes concerning automatic setting of flags and event delivery
that makes this structure necessary.
This piggy backs onto the previous changes for protocol 22 and
thus does not bump the version. This and the previous commits should be
seen as mostly atomic. Apologies for any bisecting issues this causes
(although I would expect these to be minimal)
This change doesn't add any functionality in itself, but it will be useful in
the future for operating on chains of sinks or sources that are piggy-backing
on each other.
For example, the PA_PROP_DEVICE_MASTER_DEVICE property could
be handled in the core so that each virtual device doesn't have to maintain it
separately. By using the origin_sink and destination_source pointers the core
is able to see at stream creation time that the stream is created by a virtual
device, and then update that device's property list using the name of the
master device that the stream is being connected to. The same thing can be done
also when the stream is being moved from a device to another, in which case the
_MASTER_DEVICE property needs updating.
Instead of using string contents for type identification use the address
of a constant string array. This should speed up type verifications a
little sind we only need to compare one machine word instead of a full
string. Also, this saves a few strings.
To make clear that types must be compared via address and not string
contents 'type_name' is now called 'type_id'.
This also simplifies the macros for declaring and defining public and
private subclasses.
- drop the 'virtual_' prefix from s->virtual_volume since we don't
distuingish between reference and real volumes for sources
- introduce an accuracy for source volumes: if the hardware can control
the volume "close enough" don't necessarily adjust the rest in
software unless it is beyond a certain threshold. This should save a
little bit of CPU at the expensive of a bit of accuracy in volume
handling.
- other minor cleanups
This of course makes the name 'fixed' a bit of a misnomer. However the
definitions are now like this:
fixed latency: the latency may change during runtime, but is solely
controlled by the backend, the client has no influence.
dynamic latency: the latency may change during runtime, influenced by
the requests of the clients.
i.e. fixed vs. dynamic is from the perspective of the client.
This adds pa_assert_io_context() and pa_assert_ctl_context() in addition
to a few related macros. When called they will fail when the current execution
context is not IO resp. not control context. (aka 'thread' context vs.
'main' context)
Completely rework mixer logic. This now allows controlling a full set of
elements from a single sink's volume slider/mute button.
This also introduces sink and source "ports" that can be used to choose
different input or output ports with the UI. (i.e. "mic"/"line-in" or
"speaker"/"headphones".
The mixer paths and device maps are now configered in external
configuration files and can be tweaked as necessary.
