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.
When a rewind is requested on a sink input, the request parameters are
stored in the pa_sink_input struct. The parameters are reset during
rewind processing, and if the sink decides to ignore the rewind
request due to being suspended, stale parameters are left in
pa_sink_input. It's particularly problematic if the rewrite_bytes
parameter is left at -1, because that will prevent all future rewind
processing on that sink input. So, in order to avoid stale parameters,
every rewind request needs to be processed, even if the sink is
suspended.
Reported-by: Uoti Urpala
The problem that the comment mentions doesn't actually
exist, because when the sink latency is changed to a smaller
value, the sink implementor will request the required
rewind.
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>
* If we don't have "Digital Speakers", we should say "Speakers"
instead of "Analog Speakers", and similar for other ports.
* Change "IEC958" to "S/PDIF" (more well known name)
* Add new ports and mappings for HDMI
* Change "Internal" to "Built-in" for the card name
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.
This adds API to let external sources specify what formats a sink
supports. Sinks must opt-in to allow this, and can perform some
validation if required.
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 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)
Since we currently have two mechanisms to signal a passthrough
connection (non-PCM format or PA_SINK_INPUT_PASSTHROUGH flag), we move
all the related checks into functions and use those everywhere.
This makes things more consistent, and should we decide to get rid of
the flag, we only need to change pa_sink_input_*_is_passthrough()
accordingly.
This will eventually be replaced by a hook to let clients know that the
stream has moved so that they can gracefully reconnect and renegotiate a
supported format.
This removes the passthrough flag from sinks since we will drop
exclusively passthrough sinks in favour of providing a list of formats
supported by each sink. We can still determine whether a sink is in
passthrough mode by checking if any non-PCM streams are attached to it.
This adds a get_formats() vfunc for sinks to provide a list of formats
they can support. pa_sink_check_formats() can be used during or after
routing to determine what formats from a stream the sink can support.
