The old assumption seemed to be that if a sink or source has the
DYNAMIC_LATENCY flag set, it can never change, so the fixed latency
will always be zero. This assumption doesn't hold with filter sinks
and sources that are moved around.
This fixes a crash with two module-virtual-sink instances on top of
each other, when the bottom one is moved from a sink without dynamic
latency to a sink with dynamic latency. What happened was that first
the bottom virtual sink "updated" (due to this bug nothing was
actually updated) its fixed latency to match the master sink (zero
fixed latency), and then the top virtual sink updated its fixed
latency to match the master sink. The master sink was the bottom
virtual sink, whose fixed latency should have been set to zero, but it
was not, so the pa_sink_set_fixed_latency_within_thread() failed in
the assertion "latency == 0".
An example: let's say that there's an alsa sink and two filter sinks
on top of each other:
alsa-sink <- filter1 <- filter2
With the old code, if filter1 gets moved to another sink, and the
new sink doesn't have the LATENCY and DYNAMIC_LATENCY flags set
(unlike alsa-sink), filter1's flags are updated fine in the moving()
callback, but filter2 is not notified at all about the flag changes.
With this patch, the flag changes are propagated to filter2 too.
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
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>
I was looking at a log that showed that a suspend happened (at
a strange time), but the log didn't tell me why the suspend was done.
This patch tries to make sure that that won't happen again.
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.
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>
For some reason, a badly behaving client was trying to set a NULL
port, which caused PulseAudio to crash. Add safeguards on two levels
just to be protected. (Also remove a redundant check.)
BugLink: https://bugs.launchpad.net/bugs/951273
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>
This updates corked streams' resamplers when switching sample rates on a
sink/source, which means the restriction of allowing sample rate updates
only when no streams are attached to a sink/source is now relaxed to
preventing updates only when there is a running stream attached.
pa_sink/source_used_by() ignores corked/monitor streams, but we need to
make sure there aren't any of these while updating rate (at least for
now -- this is a restriction that would be nice to get rid of).
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>
pa_{sink,source}_volume_change_apply were being called by the ALSA I/O
thread on every iteration, causing a pa_rtclock_now() call, which can
sometimes be heavy. We avoid this call by making sure there actually are
changes to apply before proceeding into the function.
While we're at it, also dropping a redundant check on s->write_volume.
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).
Sometimes the ALSA mixer can be modified during a point at shutdown
which causes a race condition trying to update the volume of an
unlinked sink.
Includes typo fix by our Chief Typo Spotter, Colin, and a clarifying
comment by me.
BugLink: http://bugs.launchpad.net/bugs/841968
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This handles the case where a virtual sink/source and it's master have
different channel counts. The solution is not ideal because if the
former has fewer channels and the master has channel volumes that are
not all at the same level, it will lose this information and have all
channels at the same level.
This is not just a theoretical problem, since module-echo-cancel
prefers a mono virtual source/sink and will usually be sitting on top of
a stereo ALSA source/sink.
That said, I don't really see a good solution to this problem, so the
idea is to make volume sharing optional (on by default) in
module-echo-cancel, so that the few people who care can then disable it
if they so desire.
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.
The callback should also be reset in reset_calbacks().
The extra check in _volume_change_apply() is needed because when the sink is unlinked the callbacks are reset,
but there still may be pending volume changes.
Some sink flags are really just a product of what callbacks
are set on the device. We still enforce a degree of sanity
that the flags match the callbacks set, but we also set the
flags automatically in our callback setter functions to
help ensure that a) people use them and b) flags & callbacks
are kept in sync.
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 was added to ensure symmetry between playback and recording streams
code, but in reality this makes little sense practically speaking and thus
it is removed.
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)
In most cases it is expected that clients cannot consume compressed
data from monitor sources, so we suspend the monitor source when the
sink goes into passthrough mode.
Eventually, when the extended API includes client notifications for
changed formats, we should emit a notification on the monitor so that
clients can decide what they want to do when this happens (disconnect or
consume the data anyway).
This allows modules to know when certain ports are changed.
This will allow e.g. a filter module (or LADSAP) to only load
when a certain port is used on the device (e.g. to only filter
headphones and not normal speakers).
(Comment from Colin Guthrie: This may also have use in UCM)
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.
When looping through the streams on a given device checking to see if the
stream is 'active' there should be no assert if the stream is not linked, it
should simply be ignored.
This assert can be hit if a sink and a sink input are both created and setup
but the final put calls are left to the end as is done in module-ladspa-sink.
While the order of the calls in module-ladspa-sink could be altered, we should
deal gracefully with the way it is now and not complain about ending up
in this state.
A trigger case was trivial:
1. Load a ladspa-sink.
2. Play a stream and move it to it.
3. Unload the module, then reload it.
4. Due to module-stream-restore and module-suspend-on-idle, the hook callbacks
will ultimately hit this assert.
Thanks to Kim Therkelsen for highlighting this issue.
