Use this to override the default $PIPEWIRE_CONFIG_DIR/media-session.d
directory. This allows us to have separate configuration directories for
pipewire and media-session.
Make things work then there is no default input device and the default
source is actually the monitor of the default sink.
Also implement lookups of monitor sources with the monitor id as the
name.
Fixes#1691
pause_node() will check the IDLE state of the node and will not
deactivate the node when suspending when it was already IDLE.
Fixes an issue where node.pause-on-idle=false filters would not want to
resume after a suspend.
If we try to fetch a property as some specific type and the parsing
fails, log a warning. This should catch any client bugs where the
properties are set wrongly.
Two method calls to get properties,
- pw_properties_fetch_$type()
- pw_properties_get_$type()
The former allows for easy error checking and conditional setting of
properties. The latter for easy fetching of a property with a default
value. This simplifies the code and makes property parsing behave more
consistently across the code base.
Before:
str = pw_properties_get(props, "foo");
if (str)
myval = pw_properties_parse_int(props, str);
if (myval == 0) /* parsing error or a valid zero */
do_stuff(myval);
Now:
if (pw_properties_fetch_int32(props, "foo", &myval) == 0)
do_stuff(myval);
If we build media-session before the daemon we have the executable
variable available and can rely on meson to fill in the path instead of
handling it manually.
There are only two values we care about that are identical, we can
re-set those in a new configuration_data() object.
All the other values set by the pipewire daemon are related to how we
start the session manager which isn't applicable here.
When pause-on-idle is false, the node can be destroyed without ever
being deactivated, which would crash. Make sure we deactivate in destroy
and remove the node from the graph.
Add a method to enable/disable the denormals flush-to-zero and
denormals-as-zero CPU options.
Add a config option to make it possible to disable this again.
Fixes high CPU usage when dealing with denormals, which can happen
in many DSP functions.
Fixes#1681
AUX channels can link to any other channel but when AUX channels are
linked, they must match exactly.
Fixes some issues with split devices with aux channels.
Some devices (Bose Mini Soundlink II, Air 1 Plus, ...) don't enable
AVRCP volume control, or fail to enable it before a hardware button is
pressed. However, these devices appear to enable it, if an AVRCP player
is present.
As a workaround, register a dummy AVRCP player for each adapter. It only
displays the current transport acquisition state as playing/stopped, but
just its presence appears to be enough to make devices behave.
Multiple AVRCP players interfere with each other, as BlueZ uses the one
registered earliest as the default player. So add also a config option
for disabling this. (It's not common to have mpris-proxy etc. running,
so defaulting to true should be OK.)
See pipewire#1157
Take some parts out of the public documentation, add a lot of internal
documentation to make it easier for the next person to figure out how
this works.
The use of static inline prevents doxygen from generating docs, put a
note in to link to the header file directly.
Re-using an id after removing it is a bug in the caller but there are
two cases where we corrupt the free list without warning:
Removing an object twice:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_remove(map, id);
And inserting an element at an index previously removed:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_insert_at(map, id, new_object);
The latter is arguably valid code, or at least it'll look like it's
valid code.
For both cases, check if the id to remove/insert at is a free item and
handle that accordingly.
The Doxygen "Modules" page is not very illuminative, as different parts
of the API are mixed together and not all parts are included.
Try to address this:
Put all parts of the public API to some Doxygen group, usually one group
per header file. Use short, systematic names.
Make these groups sub-groups of a few top-level groups, roughly
corresponding to the different logical parts of the API (core, impl,
stream, filter, spa, utilities).