Make it possible to let a plugin suggest a samplerate for the filter.
Make the convolver suggest the samplerate of the IR file anf use that
if nothing else is specified in the config.
Fixes#1659
module-zeroconf-discover loads module-pulse-tunnel for each entity
exposed on the network. Previously, however, the destroy event
of the loaded pulse-tunnel modules were not handled.
This resulted in a use-after-free because both `pw_context_destroy()`
and `module-zeroconf-discover.c:impl_free()` tried to destroy
the pulse-tunnel modules. The reason for that is that since
1de16afc40 the modules
are prepended to the module list of the context, not appended,
therefore modules are destroyed in LIFO order, thus the pulse-tunnel
modules were destroyed before the zeroconf-discover module that
loaded them.
Fix that by handling the destroy event of the loaded pulse-tunnel
modules.
Fixes#1653
Where pipewire and friends are started via socket activation,
a PA client connection to the pulse socket triggers
pipewire-pulse.service. That in turn triggers pipewire.service through
Wants/After and once that is started up, pipewire-pulse actually
starts up.
At the same time, pipewire-media-session or wireplumber are started
through WantedBy/after in the respective service files.
Depending on which leg the race condition got out of bed with today,
pipewire-pulse may be finished before the session manager has set up the
graph and the PA client doesn't see any devices.
Fix this by adding a dependency on the session manager in
pipewire-pulse, installed via an Alias so media-session and wireplumber
can install the same alias. Wants is a light dependency, so for the case
where it doesn't exist we fall back to the current behavior anyway.
This doesn't remove the race condition since systemd may deem the
session manager to have started before the graph is set up, but it
should reduce the occurances.
The disadvantage here: only one Alias will be installed by systemd, so
first-come, first-serve in the case of both media-session and
wireplumber being installed.
See #1553
Without this, a journal entry merely looks like this:
Stopping Multimedia Service ...
Which is obviously terrible from a branding perspective but also makes
it harder for users to figure out what process was responsible for this
entry.
Don't use the previously skipped sample to calculate the remaining
amount of samples or else we remove one sample too much in some cases
and cause distortion, mostly when downsampling.
Fixes#1646
Media-session itself uses ms.core, there are only two files that could
have a sub-topic but right now they don't use it (match-rules and
metadata).
The modules use the ms.mod.* namespace, so it's trivial to filter on
those.
This is more complicated than a normal module because we have two
logging topics: mod.protocol-native and conn.protocol-native for wire
messages. Because the latter use spa_debug (through spa_debug_pod) we
need to #define our way around so those too use the right topics.
Note that this removes the previous "connection" category, it is now
"conn.protocol-native" instead.
pw_log_log/logv now go through the topic-based logger using the
"default" topic. Log topics themselves can be allocated by the call
sites. The simplest way to use a topic from e.g. a module:
PW_LOG_TOPIC_STATIC(mod_topic, "mod.foo");
#define PW_LOG_TOPIC_DEFAULT mod_topic
...
void pipewire__module_init() {
PW_LOG_TOPIC_INIT(mod_topic);
...
}
With the #define all pw_log_foo() are now routed through the custom
topic. For the cases where the log topic must be specified, a
pw_logt_foo() set of macros is available.
Log topics are enabled through the PIPEWIRE_DEBUG environment variable
which now supports globs, e.g. PIPEWIRE_DEBUG="*:I;mod.access:D"
to enable global INFO but DEBUG for the access module.
Namespaces documented are "pw", "mod" and "conn", for pipewire-internal
stuff, modules and connection dumping. The latter is special-cased to
avoid spamming the log files, it requires an expcit "conn.<glob>"
pattern to enable.
The "default" topic always exists and is the fallback for any
pw_log_foo() invocation that does not use a topic.
Add a struct spa_log_topic that allows for logical grouping of messages.
The new macros spa_log_logt() and spa_log_logtv() take a topic as
argument, the topic's level acts as filter.
A new macro spa_log_topic_init() initializes a topic. By default a topic
inherits its logger's debug level but a logger implementation may set
that topic to a specific fixed log level.
The various spa_log_*() macros transparently wrap new and old
implementations:
- if the implementation is version 0, the new logt() calls drop the
topic and get routed into the old log() calls
- if the implementation is version 1, the old log() calls use a NULL
topic and get routed into the new logt() calls
All spa_log_* macros use the SPA_LOG_DEFAULT_TOPIC topic (NULL), it is
up to the caller to redefine that. Alternatively, use spa_logt_* to pass
an explicit topic.
There is one crucial flaw in this implementation: log topics are
initialized to their target level by the current logger. Where a topic
is initialized but the logger is switched later, the topic is not
automatically re-initialized. Ultimately this shouldn't matter for
real-world use-cases.
spa_interface_call() and friends will quietly do nothing if the version
doesn't match so we need an extra macro to know whether we can
spa_interface_call() for any given version.
This allows us to implement things like:
if (spa_interface_callback_version_min(1)
spa_interface_call(..., 1, func_v1)
else
spa_interface_call(..., 0, func_v0)
Intel 8087:0029 at Firmware revision 0.0 build 191 week 21 2021 on
kernel 5.13.19 produces CVSD data stream that consists of 96-byte data
packets interleaved with 96-byte zero packets.
This seems to not occur on other adapters, which usually produce only
48-byte data packets.
Don't do a blocking probe of native backend presence, because it may
trigger DBus activation for Bluez. If the DBus activation fails, it
ends up blocking until timeout.
ofono/hsphfpd usually don't have DBus activation configured, so they
fail instantly (which is why this problem was not encountered, even
though they do blocking calls on startup in previous pipewire versions
too).
Instead, select the backend once we have Bluez objects listed.
Previous commit 69e935e unconditionally called pw_log_set_level() after
the option parsing. If pw_init() changed the logging level based on
PIPEWIRE_DEBUG, we'd now overwrite that change.
Call pw_log_set_level() only if -v is actually given on the commandline.
This means a commandline option will override PIPEWIRE_DEBUG if set but
that is intended.
Fixes 69e935e8a4
spa_log_logv was missing, so with this ifdef'd out we already fail to
compile:
spa/plugins/alsa/alsa-acp-device.c:1003: undefined reference to `spa_log_logv'
And it appears that the only requirement is __VA_ARGS__ support in the
compiler which we require in other places anyway.
The tests using this function use the pw_log* macros which invoke
whichever logger pipewire has set. Since the default logging
implementation supports logging to a file anyway, let's just use that
instead of having to load the plugin ourselves.
HAVE_DATA|NEED_DATA signals that the graph can continue processing.
OK means that the node will continue asynchronously later. This
is needed to make the dummy driver work as a follower.
