This lets consumer just set SPA_DATA_MemPtr as their supported dataType and will add all by PW_STREAM_MAP_BUFFERS supported dataTypes, which are made available with the MemPtr API to the param
PW_STREAM_MAP_BUFFERS is set for inputs
This lets consumer just set SPA_DATA_MemPtr as their supported dataType
and will add all by PW_STREAM_MAP_BUFFERS supported dataTypes, which
are made available with the MemPtr API to the param
Remove -e and -d options
Manage modules in media-session.conf
Add alsa-monitor.conf that can match node/device properties with
a regex and update properties on it. All previous configuration and
more cane be done with this.
When a buffer is of type SPA_DATA_DmaBuf, the 'data' field
will be NULL - we instead have to check if the file descriptor
is valid. The current code, however, always checks if the
data is NULL, which gives a false positive for DMA-BUF buffers,
signaling an error when there is none.
Fix that by also checking if the buffer type is MemPtr together
with the NULL check of the 'data' field.
Long story short, this is something pulseaudio has since 2017 [1]. If
pipewire-pulse is aiming to be a drop-in replacement, the same behaviour
is probably expected.
I noticed that without this line I hit some issues with systemd socket
activation. In fact, it does not work properly at all. It probably has
something to do with the fact that pipewire-pulse is started for GDM
session and is somehow propagated down to my own user session.
[1] 24928d6b6f
Make a new complete event and use it instead of the start event
Use the start event at the start of the cycle
Make the profiler also log incomplete graph cycles
When a stream is marked don't reconnect, clear the target-node so that
it does not accidentally gets linked to a save target. This makes it
kill the monitor stream from pavucontrol after a client disconnects.
Remove the separate error event and merge with the done event with
error code. This then also marks the sample as done when in error
so that it gets cleaned up properly.
Fixes#486
We can't write more to the ringbuffer than its maxsize. Some clients
send more than the negotiated maxsize and cause a crash if we don't
clamp.
See #440
