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.
State can be used by remap function implementations to
speed up the remapping, e.g. by precomputing things or
even by generating specialized code for a specific channel
remapping task
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Initialization of the remap structure now happens in one place
Rename calc_map_table() to setup_remap(), copy sample format and
channel specs; the remap structure is initialized when we know the
work sample format of the resampler
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
pa_init_remap_func() only sets the appropriate remapping function, it
does not initialize the pa_remap struct
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
"i->save_muted = i->save_muted || mute" makes no sense. The intention
was most likely to use "save" instead of "mute" in the assignment.
This line originates from reverting the volume ramping code, commit
8401572fd5.
The idea of "i->save_muted |= save" is that even if the mute state
doesn't change, save_muted should still be updated, but only if the
transition is from "don't save" to "save".
Changing "!i->muted == !mute" to "mute == i->muted" is cosmetic only.
The rationale behind the old form was probably that when we still had
pa_bool_t, booleans could in theory be defined as int, so comparing
the values without the ! operator was not entirely safe. That's
unnecessary now that we use the standard bool type, which can only
have values 0 or 1.
A value of 0 for adjust_time should disable rate adjustment.
Fix a bug where a 0 value causes rate adjustment to be called
continuously instead after an unsuspend event.
Initially (in commit ef422fa4ae),
pa_make_secure_dir followed a simple principle: "make a directory, or,
if it exists, check that it is suitable". Later this evolved into "make
a directory, or, if it exists, ensure that it is suitable". But the
check remained.
The check is now neither sufficient nor necessary. On POSIX-compliant
systems, the fstat results being checked are actually post-conditions of
fchmod and fchown. And on systems implementing POSIX ACLs, fstat only
reflects a part of the information relevant to the security of the
directory permissions, so PulseAudio could accept an existing insecure
directory anyway.
Also, the check still fires on non-POSIX-compliant filesystems like CIFS.
As a user cannot do anything to fix it, just accept insecure permissions
in this case.
This parameter was never assigned, so just remove it.
Note that the only current user of this function is shmasyncq.c,
which is unused - we don't even build it. But I fixed it up anyway.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Source ports hashmap is created without value freeing function, which
results in (hashmap values) device ports not being freed when source
ports are removed or module is unloaded. This results in memory leak
during normal operation and during daemon shutdown dbus_protocol shared
object isn't unreferenced correctly, leaving dbus_protocol object in
core->shared, which causes assert when shared hashmap is checked for
isempty() before freeing.
This generates a list of deprecated things, which is accessible from
the table of contents frame. The list, however, isn't the important
thing here. The important thing is that this also prevents doxygen
from stripping all documentation for the deprecated things.
Previous discussion:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/18794
This patch also adds a description how the heuristic works and mentions that
there is a scaling factor that can be adjusted if there is audible clipping.
VOL_RELATIVE if a bit flag (1 << 4), hence we can simply do
if (vol_flags & VOL_RELATIVE) ...
instead of
if ((vol_flags & VOL_RELATIVE) == VOL_RELATIVE) ...
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Must use one way to specify volumes consistently, e.g.
+3dB +3dB, mixing different ways is not allowed, such as
40% 1000
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Example: pactl set-sink-volume "sink_name" 32000 40000
If the number of volumes provided is different than the number of channels
(excluding the case where a single volume is provided), an error message
is displayed explaining why the volumes could not be set.
patch proposed by Parin Porecha
code refactoring and commit message slightly edited by Peter Meerwald
fix bug
https://bugs.freedesktop.org/show_bug.cgi?id=77108
see getopt(3):
""By default, getopt() permutes the contents of argv as it scans, so that
eventually all the nonoptions are at the end. Two other modes are also
implemented. If the first character of optstring is '+' or the envi‐
ronment variable POSIXLY_CORRECT is set, then option processing stops
as soon as a nonoption argument is encountered. If the first character
of optstring is '-', then each nonoption argv-element is handled as if
it were the argument of an option with character code 1. (This is used
by programs that were written to expect options and other argv-elements
in any order and that care about the ordering of the two.) The special
argument "--" forces an end of option-scanning regardless of the scan‐
ning mode.""
prepend optstring with '+' to use POSIXLY_CORRECT mode
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
On Haswell hardware, there are multiple HDMI outputs capable of
digital sound output. As they were identically named, KDE's control
center was unable to distinguish them, restored the wrong profile and
thus routed sound to the wrong HDMI monitor.
Also, having identically-named menu items in other mixer applications
looks like a bug.
Now that we have a generic function in device-port.h, we can use
it instead of the custom one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We now have a port->card pointer, we can use it instead of iterating
over cards to find the correct one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Also, initialize userdata with zeros to avoid invalid pointers in
client_free().
This fixes a crash when client_free() is called before
create_client(). The whole issue could be avoided by using some other
mechanism than defer events for running the two functions, but I'll
do that change later (I have also other cleanups planned for
zeroconf-publish).
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=76184
The old code loaded cookies at the time of loading the client
configuration, which could lead to creation of multiple cookie files.
For example, when pa_client_conf_load() was called, the default cookie
file was created, and then if PULSE_COOKIE was set,
pa_client_conf_env() would create another cookie file.
This patch moves the loading of the cookie to a separate function,
which pa_context calls just before needing the cookie, so the cookie
won't be loaded from the default file if PULSE_COOKIE is set. This
patch also splits the single cookie and cookie_file fields in
pa_client_conf into multiple fields, one for each possible cookie
source. That change allows falling back to another cookie source if
the primary source doesn't work.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=75006
Avoid unpredictable behaviour in case e.g. the HOME environment
variable is incorrectly set up for whatever reason.
I haven't seen non-absolute HOME anywhere, but this feels like a good
sanity check anyway.
Servers older than 0.9.15 don't know anything about cards, and card
operations will return a NULL pa_operation object when connected to
that old server. We must check the pa_operation pointer before passing
it to pa_operation_unref(), otherwise a NULL operation will result in
a crash.
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>
