config.h needs to be consistently included before any standard headers
if we ever want to set feature test macros (like _GNU_SOURCE or whatever)
inside. It can lead to hard-to-debug issues without that.
It can also be problematic just for our own HAVE_* that it may define
if it's not consistently made available before our own headers. Just
always include it first, before everything.
We already did this in many files, just not consistently.
When we simply need to change some state for the code executed in the
loop, we can use locked() instead of invoke(). This is more efficient
and avoids some context switches in the normal case.
Including C headers inside of `extern "C"` breaks use from C++. Hoist
the includes of standard C headers above the block so we don't try
to mangle the stdlib.
I initially tried to scope this with a targeted change but it's too
hard to do correctly that way. This way, we avoid whack-a-mole.
Firefox is working around this in their e21461b7b8b39cc31ba53c47d4f6f310c673ff2f
commit.
Bug: https://bugzilla.mozilla.org/1953080
The change from 1 to 8 was done without justification in the commit
message and possibly for debug purposes. Unfortunately it breaks
negotiation with the libcamera virtual pipeline, which defaults to
4 buffers.
Set the the value to 1 again as successful negotiation - even with an
unusually low number of buffers - is usually more desirable than an
error.
Fixes: 98b7dc7c0 ("gst: don't do set_caps from the pipewire callback")
There is no need to encode the potential format in the format.dsp of
control ports, this is just for legacy compatibility with JACK apps. The
actual format can be negotiated with the types field.
Fixes midi port visibility with apps compiled against 1.2, such as JACK
apps in flatpaks.
Only react to the capture stream state change and format changes. The
playback and capture streams change state somewhat concurrently and so
the graph state might not be consistent.
Because only the capture stream will trigger the playback stream and
start the processing, we can safely react to capture stream changes
only.
If a link is a feedback link, we just need to swap the input/output
scheduling dependency.
Don't swap input/output nodes (without swapping ports) because then we
will be querying the wrong node/port pair when negotiating and cause
errors.
See #4706
The params contain the send/recv streams from the point of view of the
manager (and not the driver as was assumed before). This means we need
to swap send/recv in the driver, not the manager.
This makes things interoperate with JACK/netjack2.
See #4666
Get the clock pointer using the io_changed stream event.
and update the clock before triggering the process
The clock needs to be updated in the data loop thread
and before triggering the process so move the calls to
`pw_stream_trigger_process` from gstreamer thread context
into the data loop thread context by invoking a callback
and update the clock inside the data loop callback
before the trigger
Sometimes you want to use the convolver as a delay without adding
latency so add a latency option to tweak the automatic latency
reporting. Use this in the upmix rear delay filters.
Collect the latency of the graph in filter-chain. We do this by first
inspecting the LATENCY ports on the plugins and us the notify value as
the latency on the node.
We then walk the graph from source to sink and for each node take the
max latency of all linked upstream peer nodes. We end up with the max
latency of the graph and emit this in the graph properties.
We then listen for the graph latency property and use that to update the
process_latency of the filter-chain, which will then update the latency
on the filter-chain ports.
Fixes#4678
Make a function to create a filter. This is a pod that has all valid
defaults fixated and the invalid ones left unfixated.
Use this filter is a first attempt to negotiate a link format. The
effect is that a format will be chosen first that matches all the valid
defaults as much as possible instead of negotiating to the first thing
that matches.
Suppose we have a higher priority port with the format:
foo/bar
key: { default:1024, min:1, max:2048 }
And another port with two params:
foo/bar
key: 512
rate: 2/1
foo/bar
key: 1024
rate: 30/1
By first trying key: 1024 we negotiate to the more specific second property
with the higher rate.
Reset the ERR counters when pressing the c key. This only makes the
current pw-top start counting from 0 again, it does not change anything
globally on the server. It's still usefull because you can use it to
let it count the number of new errors since the keypress.
Destroy the sources from the io handler immediately when there is an
error so that we don't end up in endless error wakeups.
Schedule the free from the main loop and make sure only one can ever
run.
