Some modules may only be loaded once, and trying to load them
twice from default.pa makes PulseAudio startup fail. While that could
be considered a user error, it's nicer to not be so strict. It's not
necessarily easy to figure what went wrong, if for example the user
plays with RAOP and adds module-raop-discover to default.pa, which first
works fine, but suddenly stops working when the user at some point
enables RAOP support in paprefs. Enabling RAOP in paprefs makes
module-gconf load the module too, so the module gets loaded twice.
This patch adds a way to differentiate module load errors, and
make cli-command ignore the error when the module is already
loaded.
This allows us to restore the default device properly when a
hotpluggable device (e.g. a USB sound card) is set as the default, but
unplugged temporarily. Previously we would forget that the unplugged
device was ever set as the default, because we had to set
configured_default_sink to NULL to avoid having a stale pa_sink pointer,
and also because module-default-device-restore couldn't resolve the name
of a currently-unplugged device to a pa_sink pointer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89934
Currently the default sink policy is simple: either the user has
configured it explicitly, in which case we always use that as the
default, or we pick the sink with the highest priority. The sink
priorities are currently static, so there's no need to worry about
updating the default sink when sink priorities change.
I intend to make things a bit more complex: if the active port of a sink
is unavailable, the sink should not be the default sink, and I also want
to make sink priorities dependent on the active port, so changing the
port should cause re-evaluation of which sink to choose as the default.
Currently the default sink choice is done only when someone calls
pa_namereg_get_default_sink(), and change notifications are only sent
when a sink is created or destroyed. That makes it hard to add new rules
to the default sink selection policy.
This patch moves the default sink selection to
pa_core_update_default_sink(), which is called whenever something
happens that can affect the default sink choice. That function needs to
know the previous choice in order to send change notifications as
appropriate, but previously pa_core.default_sink was only set when the
user had configured it explicitly. Now pa_core.default_sink is always
set (unless there are no sinks at all), so pa_core_update_default_sink()
can use that to get the previous choice. The user configuration is saved
in a new variable, pa_core.configured_default_sink.
pa_namereg_get_default_sink() is now unnecessary, because
pa_core.default_sink can be used directly to get the
currently-considered-best sink. pa_namereg_set_default_sink() is
replaced by pa_core_set_configured_default_sink().
I haven't confirmed it, but I expect that this patch will fix problems
in the D-Bus protocol related to default sink handling. The D-Bus
protocol used to get confused when the current default sink gets
removed. It would incorrectly think that if there's no explicitly
configured default sink, then there's no default sink at all. Even
worse, when the D-Bus thinks that there's no default sink, it concludes
that there are no sinks at all, which made it impossible to configure
the default sink via the D-Bus interface. Now that pa_core.default_sink
is always set, except when there really aren't any sinks, the D-Bus
protocol should behave correctly.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=99425
The "profile->card != c->card" check always evaluated to false, so the
CardProfileUpdated signal was never sent. The reason: call_data was
assigned to a pa_card_profile pointer, but the correct type is a pa_card
pointer.
for example, in case HAVE_MEMFD is #undef, checking with #if HAVE_MEMFD
gives a warning (gcc 5.4.1, Ubuntu)
pulsecore/shm.c: In function 'sharedmem_create':
pulsecore/shm.c:208:5: warning: "HAVE_MEMFD" is not defined [-Wundef]
#if HAVE_MEMFD
use #ifdef or #if defined() to check for presence of a #define
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
We ended up dealing with it once in module init, and once more in the
new module callback. Avoiding it in the second case by name seems to be
the cleanest solution (else, we need to store the module index somewhere
in pa_dbusiface_core, which seems about as bad).
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
Commit ae415b07a0 ("dbus: Use hooks for
module new and removed events") changed the new module monitoring from
the asynchronous subscription system. Previously handle_load_module()
created the new pa_dbusiface_module object before we got
a notification of the loading of the module, but now we get the
notification already within the pa_module_load() call. That resulted
in a crash, because the module_new_cb() created the
pa_dbusiface_module object before pa_module_load() returned, and then
handle_load_module() would create another pa_dbusiface_module object
for the same module.
This patch removes the pa_dbusiface_module_new() call from
handle_load_module(). module_new_cb() is now responsible for all
pa_dbusiface_module object creations, except the ones that are created
during the initialization of module-dbus-protocol.
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
From the NetBSD manual:
The first argument of these functions is of type int, but only a very
restricted subset of values are actually valid. The argument must either
be the value of the macro EOF (which has a negative value), or must be a
non-negative value within the range representable as unsigned char.
Passing invalid values leads to undefined behavior.
-- ctype(3)
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.
Fixes warning: 'new_active' may be used uninitialized in this function,
and could potentially cause erronous behaviour in case an invalid port
name was specified.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The old code tried to look up the port object by using an object path,
but the ports hashmap uses port names as keys, so the method failed
always.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=85369
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
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.
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.
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
the sample format value.
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
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.
This patch removes all tabs hidden inside the source tree and replaces
them with 4 spaces.
Command used for this:
find . -type d \( -name bluetooth \) -prune -o
-regex '\(.*\.[hc]\|.*\.cc\)' -a -not -name 'reserve*.[ch]'
-a -not -name 'gnt*.h' -a -not -name 'adrian*'
-exec sed -i -e 's/\t/ /g' {} \;
The excluded files are mirrored files from external sources containing
tabs.
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.
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.
In practice there is always at least one profile, and I
don't think there will ever be cards without profiles.
Therefore, I added assertions to pa_card_new() stating that
the card new data must always contain at least one profile.
Now a lot of code can be simplified, because it's guaranteed
that the profiles hashmap and the active_profile field are
always non-NULL.
