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>
Module-device-restore sets reference_volume, but soft_volume remains at
zero dB, so if a device only has soft_volume (i e no hw volume controls),
its volume was not restored correctly.
Reported-by: Richardo Salveti de Araujo <ricardo.salveti@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This makes it easy to log a message every time the reference ratio
changes. I also need to add a hook for reference ratio changes, but
that need will go away if the stream relative volume controls will be
created by the core in the future.
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.
