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.
Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported.
When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected.
When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected.
Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
