Pipewire uses a rate of 256/7680 with the integrated camera of Apple
silicon Macbooks. To calculate pw_time.delay correctly in this case it
has to be divided by time->rate.num. Without this division the delay
contribution of the `((latency->min_ns + latency->max_ns) / 2)` term
ends up as 255 which are 8.5 seconds.
pipewiresrc reports the delay as latency in the gstreamer pipeline which
results in rendering a frame every 8.5 seconds.
I suspect the non-normalized rate of 256/7680 is another bug in
pipewire. The rate for an UVC webcam is reported as 1/30. Both
Video4Linux2 devices report a discrete frame interval of 0.033s (30fps).
Fixes#4957
(cherry picked from commit f03021edd1)
When we fire the timer event, mark the next timeout as NULL because
nothing else is going to timeout anymore until we rearm the timer.
This has the effect that if we cancel and add the same timer from the
callback that we will reprogram the timer with the new timeout instead
of thinking the item as already programmed.
do_node_unprepare runs in both the server and the client when a node is
stopped. On the server size, set the status to FINISHED and trigger any
targets. This ensures the node will not be scheduled in this cycle
anymore. We have to do this because we can't know if the node is still
alive or not.
When the client receives the stop message, it will unprepare and set the
status to INACTIVE. This ensures the driver will no longer trigger the
node. If the server didn't already trigger the targets, do this in the
remote node then.
This avoid a race where both the client and the server are setting the
status and if the INACTIVE state is set by the server, it might stall
processing of the client.
Fixes#4840
Previously the pointer was determined as follows:
mm->this.ptr = SPA_PTROFF(m->ptr, range.start, void);
however, when `pw_map_range` is calculated, `pw_map_range::start` is the offset
from the beginning of the first page, starting at `pw_map_range::offset`.
This works correctly if `memblock_map()` runs because that will map the file
with expected offset, so using `range.start` is correct.
However, when a mapping is reused (i.e. `memblock_find_mapping()`) finds something,
then `range.start` is not necessarily correct. Consider the following example:
* page size is 10
* one memblock with size 20 (2 pages)
* the applications wants to mappings:
* (offset=5,size=10)
* (offset=15,size=5)
After the first request from the application, a `mapping` object is created
that covers the first two pages of the memblock: offset=0 and size=20. During
the second request, the calculated `pw_map_range` is as follows:
{ start = 5, offset = 10, size = 10 }
and the only previously created mapping is reused since (0 <= 5) and (10 <= 20). When
the pointer of the mapping is adjusted afterwards it will be incorrect since `m->ptr`
points to byte 0 on page 0 (instead of byte 0 on page 1 -- that is assumed). Thereforce
the two will unexpectedly overlap.
Fix that by using `offset - m->offset` when adjusting the mapping's pointer. Also move
the `range` variable into a smaller scope because it only makes sense there. And add
a test that check the above previously incorrect case.
Fixes: 2caf81c97c ("mem: improve memory handling")
Fixes#4884
Remove the QUEUED flags to check if a buffer is in some queue.
Add a new flag to check if a buffer was dequeued by the application.
Check if the application only queues buffers with the DEQUEUED flag set.
The flag was used to see if a buffer was in a queue or not but that
doesn't really matter much and with the DEQUEUED flag we can only move
buffers from dequeued to queued.
When renegotiating stream parameters (e.g. size), the buffers
are cleared should no longer be queued back. Add a flag to detect this,
while logging a warning and erroring out when the user tries to queue
such a buffer.
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.
Commit b160a72018 introduced this change
before, but it was omitted in e1e0a886d5.
This makes again sure we don't call process callback while disconnecting
stream.
Fixes#3314
Make the state_changed event and _get_state() function set errno with
the current error value if the state is in error, so that application
can use this to give more detailed error reporting.
Use this in alsa, v4l2 and pulse to give some other error codes than
EIO.
Fixes#4574
The transport update is set in the node properties. If one client tries
to start and another tries to stop we have two conflicting desired states
in the nodes.
Fix this by making the state update a one time property and remove it
from the sever and client properties after updating it. We then need to
keep the new state around and apply it once.
Keep the node driver state as it is unless there was a transport state
update.
Fixes#4543
Some of the tools would like to connect to the manager socket first
because they are manager style apps. They however completely ignore any
of the configured sockets in the config and assume everything is the
default.
Fix this by adding a remote.intention = "manager" to those apps. This
instructs the protocol to first try to connect to a socket with the
-manager extension before attempting the regular configured socket.
This makes things work when you have sockets configured in /tmp
and have remote.name = /tmp/pipewire-0 in the config.
We keep on calling the drain event for as long as we are drained. The
application is supposed to inactivate the stream or provide more data
at some point.
Because we do this from the data thread, we use a non-blocking invoke.
If for some reason the event callback takes a long time we might place a
lot of these invoke calls into the invoke queue, which will then be
dispatched one after another (and cause more blocking or a burst of
useless invoke calls).
Avoid this by only placing one drain invoke call into the queue at a
time.
Fixes#4529
If a provider uses the stream API and pushes a buffer to the stream
after the stream is set to paused, the buffer_id of the last buffer
remains in the io.
If a consumer starts streaming in this state, the buffer_id of the old
buffer is still in the io. The consumer receives a stale buffer_id and
may discard the buffer. Now the buffer is lost, since it is still marked
as busy on the producer.
This can be reproduced by starting Weston with the PipeWire backend and
repeatedly restarting a GStreamer pipeline that connects to the Weston
output. Eventually Weston won't be able to dequeue buffers since the
lost buffer is still busy.
Clear the buffers in the io when the buffers are cleared to avoid
sending an old buffer_id to the consumer.
If the rate is 0/0, converting nsec to ticks doesn't work and will
result in 0 ticks, and it is not possible to convert ticks back to a
timestamp.
This can be reproduced by connecting a GStreamer pipewiresrc to a
libcamera node. The libcamera-utils has a rate of 0/0 and the
pipewireclock won't be able to determine a correct time with that. This
error was caused by Commit 89993a3cc6 ("gst: enable the pipewire ticks
as a clock source").
Fix this by using the nsec as ticks and setting the appropriate rate.
We now automatically move non-rt clients into non-rt threads so the
client-rt.conf is obsolete.
Move the module-rt in client.conf and add conditions to disable modules.
Transparently load client.conf in case applications still specify
client-rt.conf.
Custon configuration in the client-rt.conf.d/ should be moved to
client.conf.d/
Wireplumber and other system services use local real time timestamps in
logging, so it's more convenient if also PW uses them.
Add env var for selecting the timestamp type, default to "local".
Copy the server value to the context so that the locally allocated
buffers match the server quantum-limit and we don't cause xruns because
of too small buffers.
See #4490
Since fc49c1697a ("context: improve negotiation") it is possible
that the out parameter `format` will be set to `filter`. However,
`filter` is a SPA POD from the local SPA POD builder `fb`, which
references the local buffer `fbuf`.
In those cases, if the callers then make use of the returned SPA POD,
a stack use-after-free happens, such as the one displayed below.
The issue could be reliably triggered by executing the `video-play`
example program, and then trying to use the same camera in firefox.
As seen below, the input node, firefox's, provides no format preference,
causing the output format to be used. Previously, this had led
to the use-after-free described above.
pw.link | [impl-link.c: 130 link_update_state()] (46.0.1 -> 114.0.0) init -> negotiating (paused-configure)
pw.context | [ context.c: 935 pw_context_find_format()] 0x51e000000080: finding best format 3 1
pw.context | [ context.c: 943 pw_context_find_format()] 0x51e000000080: states 3 1
pw.context | [ context.c: 958 pw_context_find_format()] 0x51e000000080: Got output format:
pw.context | [ context.c: 959 pw_context_find_format()] video/raw
pw.context | [ context.c: 959 pw_context_find_format()] format : (Id) YUY2
pw.context | [ context.c: 959 pw_context_find_format()] size : (Rectangle) 640x480
pw.context | [ context.c: 959 pw_context_find_format()] framerate : (Fraction) 30/1
pw.context | [ context.c: 966 pw_context_find_format()] 0x51e000000080: no input format filter, using output format: Success
=================================================================
==418404==ERROR: AddressSanitizer: stack-use-after-return on address 0x73993ee46200 at pc 0x739941d31020 bp 0x7fff526b4670 sp 0x7fff526b4660
READ of size 4 at 0x73993ee46200 thread T0
#0 0x739941d3101f in spa_pod_builder_raw ../spa/include/spa/pod/builder.h:150
#1 0x739941d3b35d in do_negotiate ../src/pipewire/impl-link.c:294
#2 0x739941d46214 in check_states ../src/pipewire/impl-link.c:727
#3 0x739941f14405 in process_work_queue ../src/pipewire/work-queue.c:64
#4 0x73993d0dbe99 in source_event_func ../spa/plugins/support/loop.c:894
#5 0x73993d0d6881 in loop_iterate ../spa/plugins/support/loop.c:727
#6 0x739941d76b05 in spa_loop_control_enter ../spa/include/spa/support/loop.h:264
#7 0x739941d76d93 in spa_loop_control_leave ../spa/include/spa/support/loop.h:268
#8 0x739941d78946 in pw_main_loop_quit ../src/pipewire/main-loop.c:109
#9 0x5a64b3cb1cec in main ../src/daemon/pipewire.c:130
#10 0x739940c34e07 (/usr/lib/libc.so.6+0x25e07) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#11 0x739940c34ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#12 0x5a64b3caf3b4 in _start (/pipewire/build/src/daemon/pipewire+0x173b4) (BuildId: f9e8403a377e28bf8bd9cf0a5b89d33f08499917)
Address 0x73993ee46200 is located in stack of thread T0 at offset 512 in frame
#0 0x739941c6ed5e in pw_context_find_format ../src/pipewire/context.c:907
This frame has 15 object(s):
[...]
[432, 480) 'fb' (line 911)
[512, 4608) 'fbuf' (line 912) <== Memory access at offset 512 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return ../spa/include/spa/pod/builder.h:150 in spa_pod_builder_raw
[...]
Fixes: fc49c1697a ("context: improve negotiation")
When calculating the adjusted max quantum based off of max_latency, the
first multiplication can overflow uint32_t, leading to the quantum being
wrongfully clamped down.
Signed-off-by: Martin Louazel <martin.louazel@streamunlimited.com>
We increment the refcount of the loop when we hand it out. We use this
refcount to do some load balancing. In some cases we also decrease the
refcount again when the release_loop() functions is called but we only do
this in some modules. The result is that in most cases the refcount
just keeps on going up and this is misleading.
Change the refcount to a last_used timestamp and prefer to use loops
that have not been used in a while.
Fixes#4436
Some clocks (v4l2) don't process exactly process buffers at the given
rate/duration so mark this in the clock flags.
We need to use the nsec field in the clock to derive ticks in pw-stream
in that case to get a good clock.
Remove the check for the target rate and duration. The drivers are
supposed to update that now.
The check is a little racy because a new target could have been
configured right after the driver emitted the ready signal. In that
case we should not update the clock values but let the driver run with
the old values and let the new values become active in the next cycle.
