This fixes assertion failures that manifest themselves with cards that
support only weird rates such as 37286Hz. Tested with snd-pcsp.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=48109
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.
Currently the alsa sink and source write directly to s->muted during
initialization, but I think it's better to avoid direct writes, and
use the set_mute() function instead, because that makes it easier to
figure out where s->muted is modified. This patch prevents the
set_mute() call from crashing in the state assertion.
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.
In case a port has not yet been saved, which is e g often the case
if a sink/source has only one port, reading volume/mute will be done
without port, whereas writing volume/mute will be done with port.
Work around this by setting a default port before the fixate hook,
so module-device-restore can read volume/mute for the correct port.
BugLink: https://bugs.launchpad.net/bugs/1289515
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
When given an explicit device.description in card_properties, prefer
this information over other default prefixes (e.g. 'Built-in Audio')
when constructing sink/source descriptions.
For example, if I manually configure the card description to be
"FooBar", I then expect that the sinks and created by the card also
have "FooBar" in their description instead of generic "Built-in
Audio".
I think this makes the code a bit nicer to read and write. This also
reduces the chances of off-by-one errors when checking the bounds of
sample rate values.
Since the hashmap stores a pointer to the key provided at pa_hashmap_put()
time, it make sense to allow the hashmap to be given ownership of the key and
have it free it at pa_hashmap_remove/free time.
To do this cleanly, we now provide the key and value free functions at hashmap
creation time with a pa_hashmap_new_full. With this, we do away with the free
function that was provided at remove/free time for freeing the value.
If the sink rate is not updated, then the monitor source will appear
to have a different rate than the sink, but in reality there's never
any resampling done when moving data from the sink to the monitor
source, so it's a lie that the monitor source has a different rate.
The result of lying is that clients that capture from the monitor
source will have streams that run too fast or slow.
When a sink changes its sample rate, also the monitor source rate
needs to be changed. In order to determine whether a source supports
rate changing, the code checks if the update_rate() callback is set,
but monitor sources don't have that callback set, so the old code
always failed to change the monitor source rate.
This patch fixes the monitor source rate changing by handling monitor
sources as a special case in pa_source_update_rate(): if the source is
a monitor source, then the update_rate() callback is not required.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=66424
This patch removes all occurrences of double and triple
newlines.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-a -not -name 'adrian-aec.*' -a -not \
-name reserve.c -a -not -name 'rtkit.*' \
-exec sed -i -e '/^$/{N;s/^\n$//}' {} \;
Two passes were needed to remove triple newlines.
The excluded files are mirrored files from external sources.
This patch replaces every occurrence of ')\n{' with ') {'.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-a -not -name core-util.c -a -not \
-name adrian-aec.c -a -not -name g711.c \
-exec sed -i -e '/)$/{N;s/)\n{$/) {/}' {} \;
The excluded files are mirrored files from external sources.
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.
