Add check for running the the loop context and thread.
Add checks in filter and stream to avoid doing things when not run from
the context main-loop because this can crash things when doing IPC from
concurrent threads.
Rework the runnable state calculation. It works in 2 steps now:
1. Collect all nodes linked to a driver in some way. Mark nodes that
are reachable with a non-passive link as runnable.
2, Go through all runnable nodes and set all linked nodes to the
runnable state as well, up to the driver.
Step 2 is new. Previously if there was just one runnable node, *all*
nodes would be set to runnable. With the addition of step 2, some nodes
might remain idle when they are not used.
This has the effect that virtual sinks without inputs stay idle when
the driver is otherwise running. Grouped nodes (like the RTP session)
will now also only run the linked nodes.
This reverts commit 2bfe772bb4.
This does not take into account nodes recursively becomming runnable and
so does not set the runnable state on all nodes correctly, like for
combine-stream.
Revert for now, it probably requires a new algorithm to make this work.
See #3128
If you set node.force-rate=0, the rate will be forced to the node.rate
denominator.
This makes it possible to autiomatically make the graph switch to the
native rate of the stream by setting this as the default property on
streams.
See #3026
There is no point in trying to restore a node to the default rate when
it's not going to run.
This avoids loops when rate switching from one forced rate to another.
Make sure we allocate at least 2 buffers when we are dealing with an
ASYNC node. This ensures that an adapter without a converter will at
least negotiate to 2 buffers when the follower stream is async (such as
is the case with pw-cat).
We need to be able to fill up one quantum of data when the stream
requests it so suggest a quantum_limit buffer size. Normally, the
converter will further improve the buffer size parameters when
resampling is involved but this is a good default for when working in
passthrough mode.
We don't actually use the stream buffering features so we're happy with
just 1 or 2 buffers.
Only make a passive link when one of the peers is passive and the other
one can be suspended or when both are explicitly passive.
This avoid making passive links between a sink/source pair.
It also avoid making passive links between two streams if they are not
explicitly marked as passive.
It does allow making passive links between a passive stream and a
sink/source or between two passive streams.
This reverts commit 6a64b4461e.
Now that sinks and sources are no longer passive by default, we need
just one part of the link to be passive to make things passive.
This breaks the stream recording from a passive stream case but we can
find a different fix for that later.
Nodes with the same link-group should be added to the same driver.
Also the runnable state of the nodes in the same link group is
shared between eachother. This makes it look like the linked nodes are
really just one big node.
With this change we correctly calculate the state of all nodes and we
can then only set the running state on the runnable nodes.
If you have 2 loopback sinks in front of a driver, this change will
only make the used loopback sink running and keep the other one
idle. It also works for grouped nodes, where only the active nodes
will now be running (such as rtp-session nodes).
Make an option to allow link.passive properties and set it to false by
default.
This effectively ignores the link.passive properties from the session
manager, jack clients and pw-link when set. This is a good idea because
the logic for making passive links is better handled in the core.
Don't increment the required activation count every time we change the
node prorties with a TRIGGER property. Only increment/decrement when the
value actually changed.
We are not allowed to call pipewire methods from any other thread than
the main thread so use invoke to schedule a module unload from the
pulseaudio thread.
Fixes some infinite loops when the work-queue list gets corrupted.
These drop-ins are not meant to be enabled by default, so let's move
them to fontconfig style *.conf.avail/ subfolders from which they can
be copied or symlinked to a location that will get merged into the
corresponding configuration file.
Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com>
Filling a buffer with zeros to produce silence is wrong for
unsigned sample formats and compressed sample formats. This is
silence with an offset. A silent stream with unsigned or
compressed samples mixed with another stream produces a clipped
stream. To hear the problem start QEMU with
qemu-system-x86_64 -accel kvm -smp 4 -m 4096 \
-audiodev pa,id=audio0,out.mixing-engine=off \
-machine pc,pcspk-audiodev=audio0 \
-device ich9-intel-hda -device hda-duplex,audiodev=audio0 \
-boot d -cdrom Fedora-Workstation-Live-x86_64-37-1.7.iso
on a host configured to use PipeWire and start audio playback on
the guest HDA device.
PA_SAMPLE_U8 is the only unsigned PulseAudio sample format.
There is no need to care about unsigned multi-byte formats.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Drivers should only read the target_ values in the timeout, update the
timeout with the new duration and then update the position.
For the position we simply need to add the previous duration to the
position and then set the new duration + rate.
Otherwise, everything else should read the duration/rate and not use
the target_ values.
Place the target rate and duration in the io clock area.
The driver is meant to read these new values at the start of the cycle
and update the position rate and duration.
This used to be done by the pipewire server when it received the ready
callback from the driver but this is in fact too late. Most driver would
start processing and set the next timeout based on the old rate/duration
instead of the new pending ones.
There is still a fallback for the old behaviour (with a warning) when
the driver doesn't yet update the position.
Keep track of when a rate was forced on a driver and restore the
best rate again when no longer forced.
This handles:
- paplay playing a file at 44100Hz
--> driver openeing the device at 44100
- PIPEWIRE_PROPS='{ node.force-rate=48000 }' jack_simple_client
--> driver being forced to a new rate of 48000
- Stop jack_simple_client
--> Driver reverting back to 44100
Previously the driver would stay in 48000Hz until it idles.
This also works with pw-metadata -n settings 0 clock.force-rate 0.
Fixes#2133
When we already have a pending rate/quantum change, don't reconfigure
the driver.
This avoids going into an endless loop when:
1- paplay plays with 44100Hz on device1
2- jack_simple_client starts and attaches to device1
3- jack_simple_client links to device2
4- jack_simple_client is moved from device1 to device2, rate from
device1 is moved to device2 (44100Hz)
5- device2 becomes schedulable and sees the rate should be 48000Hz (the
default) it does a rate switch to 48KHz
6- jack_simple_client is suspended, links are back to init
7- jack_simple_client is moved back to device1
8- jack_simple_client links are activated and cycle restarts at 4
The cycle is broken because at 6 we avoid doing the suspend.
But instead ship config override files to enable it again.
The idea is that distros can make extra packages that can than be
installed to enable the upmixing.
Also ship a config file to enable more samplerates.
Fixes#3081
Emit both the bound_id and bound_props events from the protocol on
the core_resource.
Doing the dispatching of the bound_id/bound_props in the core to the
proxy doesn't handle the case where the client has a listener directly
on the core_resource.
Fixes#3109
this event extends the bound_id event and sends the global properties as
well.
This can be used to get the object.serial, for example.
It can also be used in the future to let the server generate unique
property values, like the node.name, and let the client know about the
new property value.
