We're missing the delay in samples plus all of the extra samples of
silence we use to restart the device. This is in the samplerate of
the device.
Convert this to the time domain of the graph before adding it to xrun.
The isinf function returns -1 for negative infinity on glibc, but
the standard guarantees no such behavior (e.g. in C++ it always
returns a bool, on musl libc it's a macro that expands to a bool
expression), saying just that it returns a non-zero value.
This was added in pulseaudio around 15 years ago, and was never
fixed; pipewire then got the code from it. However, we can portably
check against -INFINITY instead (from math.h, already included).
Ref 045c1d6
If the modifier for a format is not fixated yet, we will use vulkan to
fixate a modifier, update the parsed format, change the EnumFormats mask
and exit early. This triggers a new enum_params with EnumFormats and a
new set_param for Format.
This commit add helpers to create and to import a DmaBuf via the
external_dmabuf_info struct.
The import path is based on the image creation of wlroots and the create path is
inspired by the wlroots vulkan allocator MR.
vulkan_wait_idle waits until the device is idle and all referenced
objects can be destroyed.
vulkan_wait_fence waits until a fence is triggered by a finished
queueSubmit.
vulkan: wait on fence
This commit should just shuffle code around with no functional changes.
The goal is to ease development of simple vulkan nodes by providing
generic helpers.
The default period is based on the default rate and might be too small
when using high samplerates. Scale the rate with the samplerate and make
sure it's a power of 2 to avoid trouble.
Fixes#3444
Let the source write into a ringbuffer when there is data available.
We then read from the ringbuffer when scheduled and use a dll to keep
the delay constant. We can later make this a driver and use the rate
correction to tweak the timeouts instead of resampling.
See #3478
Round down the size and avail to the frame size to make sure we always
send aligned frames.
When we don't have the required size, set the buffer to 0 but still send
whatever we have in the ringbuffer or else it stays there until some
unknown time when it gets flushed out again with new data.
When we don't manage to emit the notify, still mark the object as
registered. Otherwise we might not emit the unregistered
notify later on.
This usually happens when a client connects and the notifies are
suppressed for all the objects in the graph. When they later disappear
we do want to emit the unregistered notify.
The tag param has a list of arbitrary key/value pairs. Like the Latency
param, it travels up and downstream. Mixers will append the info
dictionaries or do some more fancy merging.
The purpose is to transport arbirary metadata, out-of-band, through the
graph and it's used for stream metadata and other stream properties.
When we don't have a pending target duration/rate update, take the
currently configured clock target duration/rate as the target rate.
This needs to be done when the driver refuses to update the duration and
rate for some reason and places its own values in clock target duration/rate.
Otherwise we would think the driver is using some other duration than
what it is really using.
Try:
- set alsa to irq based playback that refuses to change the quantum
- paplay with some file that sets the quantum to 1024
- pw-metadata -n settings 0 clock.force-quantum 256
- the target duration will be set to 256 but alsa doesn't change it
- stop playback
- start playback again, the quantum is still 1024 and not 256
Add an xrun counter in the clock that accumulated the duration of
xruns. Fill this in in alsa-pcm.
A client could use this to dectect xruns (when it changes) and to align
the position and nsec after an xrun.
We can't really do zero copy because our downstream peer does not have
access to the memfd of our upstream peer. Instead, just memcpy the
data for now.
Don't just stop scanning the link groups after we tried one direction,
also try the other direction.
Otherwise:
source -> loopback1_in|loopback1_out -> loopback2_in|loopback2_out -> record
will first scan from loopback2_out downstream and finds loopback2_in in the same
group but without downstream links. Then when upstream scan is done,
loopback2_out is already scanned and will be skipped and so loopback1
stays IDLE.
We fix this by keeping track of the direction that we scanned a node in
and only stop when we scanned it in the same direction twice.
