Start with an extra period of silence.
Reconfigure a new timeout if we are too far off from the desired
buffer fill level. Reduce this level to the maximum error we
tollerate.
With this we use the extra period of silence to reconfigure the
timeout until we are close enough and we can start the dll with a
small error.
See #892
Don't always try to restore the saved profile when it's available
but only do this the first time. From then on, try to follow the
best profile when it changes.
If a driver node is linked with a non-passive link to itself, it
should also become running.
One example of this is the Midi bridge, that needs to start when you
link one device to another. The devices are all on the same node
so linking devices would result in loopback connections.
libcamera + bluez5 devices should be freed/unloaded via the sm_object
free callback, similarly as in alsa and v4l2 monitors. This ensures
they are run at session_shutdown.
To resolve monitor and policy core global ids racing with each other,
use separate registry event handlers for both cores. Each handles only
their own objects, determined by where the object handle was created.
Postpone handling of policy core new global events after monitor sync,
which orders them after the corresponding monitor proxy and registry
events. Monitor core is then more up-to-date, so we resolve id clashes
in favor of monitor globals, which avoids duplicate objects.
Fix use-after-free by tracking whether a monitor holds references to
sm_object. Keep also objects pending for id in a list, so that they can
be cleaned up on session_shutdown (monitors may leak objects at
shutdown, because spa objectinfo events won't be handled then).
Caveats:
Zombie objects may still created if policy core is late by several
events, but in those cases the corresponding remove events are already
in the queue.
Also, there's a (theoretical) possibility that pw_registry_bind will
bind the wrong object, if the registry event is handled too late and an
id is reused by the server.
For details, see reverted 77e4fdb1e4
for which this is a another approach.
Pass the right value for the rate, we need to pass the graph rate.
Don't reduce bandwidth, it is not needed.
Fixes timings for reading the alsa-sequencer.
Don't try to move closer to the read/write pointers in the ringbuffer
to compensate for the resampler delay. We might not have enough time
anymore to complete a cycle without xruns. The delay is properly
reported in the clock times and should also be reported on the port
latency eventually.
This simplifies the code and also avoids a warning with _FORTIFY_SOURCE:
../pipewire/src/modules/module-protocol-pulse/pulse-server.c: In function ‘create_pid_file’:
../pipewire/src/modules/module-protocol-pulse/pulse-server.c:6028:2: warning: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
6028 | write(fd, pid_str, strlen(pid_str) + 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid calling memset on a large piece of memory when draining
the resampler because it might use up all the allocated time in
our realtime thread. Instead use a prealloced empty buffer.
In the inactive state, use the configured latency values for the
node instead of the current values used in the graph. We need to
do this because the graph only changes the buffer-size to our
requirements when the node becomes active.
Some clients do get_buffer_size before activating and would then
get a different value from when they would activate, causing some
apps to be confused and stop.
See #886
Make arrays from config sections that should really be an array.
Having the module name as the object key technically makes it
impossible to load the same module twice because the key can only
be once in the object.
The same applies to the context.objects and context.exec sections.
This also makes it somewhat easier to parse the config..
Keep all the children param flags around and use those to decide
if something changed. Also don't change the param flag serial when
we are simply adding a listener.
This should reduce the number of param updates, most notably the
PropInfo that was updated along with the Props on volume changes.
