The ringbuffer can't be written to from multiple threads.
When both the main loop and data thread do _invoke, they both write to
the ringbuffer and cause it to be corrupted because the ringbuffer is
not multi-writer safe.
Doing invoke from the thread itself is usually done to flush things out
so we really only need to flush the ringbuffer and call the callback.
See #1451
Make a new PW_KEY_NODE_WANT_DRIVER to assign the node to a running
driver. (does not work yet)
Use a new variable to hold the ALWAYS_PROCESS setting and also
update want_driver.
This makes things it a bit more future proof.
Virtual sinks and sources implemented with streams need to be grouped
with a driver node to be able to schedule. We don't have a way to let it
use a default driver so add it to the pipewire.dummy driver.
This fixes stalled pipe and other streams streams.
Fixes#1407
We always want to clear the provided blocklist from the properties. The
logic tries to only clear when there was a blocklist but it checks this
by comparing the string pointer to the fallback, which gives a compiler
warning.
`getpwuid_r()` puts the strings pointed to from the returned
passwd struct into the specified buffer. Previously, that
buffer technically didn't live long enough to be usable
in the `snprintf()` call - although in practice this didn't
appear to be a problem. A particular version of GCC 11 generates
the same machine code for this function regardless whether
this patch is applied or not. Still, fix this by moving
the buffer to an outer scope.
The getrandom() detection from meson.build fails with the following error
message:
.../host/x86_64-buildroot-linux-uclibc/sysroot/usr/include/sys/random.h:27:35: error: unknown type name 'size_t'
27 | extern int getrandom(void *__buf, size_t count, unsigned int flags)
| ^~~~~~
.../host/x86_64-buildroot-linux-uclibc/sysroot/usr/include/sys/random.h:8:1: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
Fix it by adding stddef.h include to the meson getrandom() detection.
Fixes:
../src/pipewire/impl-core.c:54:9: error: conflicting types for ‘getrandom’
54 | ssize_t getrandom(void *buf, size_t buflen, unsigned int flags) {
| ^~~~~~~~~
In file included from ../src/pipewire/impl-core.c:34:
.../host/x86_64-buildroot-linux-uclibc/sysroot/usr/include/sys/random.h:27:12: note: previous declaration of ‘getrandom’ was here
27 | extern int getrandom(void *__buf, size_t count, unsigned int flags)
| ^~~~~~~~~
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/pipewire/0001-meson-fix-getrandom-detection-for-uclibc.patch]
module-switch-on-connect sets the configured default sink/source
whenever suitable new sink/sources appear.
This should give the same behavior as Pulseaudio's module.
This module exists mainly to provide a workaround e.g. for desktop
environments such as XFCE, whose mixer applications try to manage the
default devices assuming fully PA-like behavior, breaking default
pipewire output switching.
Reorganize the docs a little. First a short intro, then list the use
cases, then the responsabilities of the various components, then
the implementation in various places.
To fix build warning about a variable being unused in LibCamera::stop():
[1/2] Compiling C++ object spa/plugins/libcamera/libspa-libcamera.so.p/libcamera_wrapper.cpp.o
../spa/plugins/libcamera/libcamera_wrapper.cpp: In member function ‘void LibCamera::stop()’:
../spa/plugins/libcamera/libcamera_wrapper.cpp:531:58: warning: unused variable ‘buffer’ [-Wunused-variable]
531 | for (const std::unique_ptr<FrameBuffer> &buffer : this->allocator_->buffers(stream)) {
| ^~~~~~
The SPA plugin is including a <libcamera/buffer.h> header file, but this
got renamed to <libcamera/framebuffer.h> to match the defined class name:
../spa/plugins/libcamera/libcamera_wrapper.cpp:52:10: fatal error: libcamera/buffer.h: No such file or directory
52 | #include <libcamera/buffer.h>
| ^~~~~~~~~~~~~~~~~~~~
Fixes#1435
If socket write results to EAGAIN/EWOULDBLOCK or rx data starts late,
spa_bt_sco_io_write may return 0, and we should give up and skip ahead
(and not loop in RT thread with very small timeout).
When we remove a default node, remove it from the properties and trigger
a save of the state so that the configured default is also actually
removed from the state file.
- use meson to check for gettid() function, always use if available
- use syscall fallback on linux, if not
- restrict thr_self() fallback to *only* FreeBSD
- error out if there isn't any gettid impl
We should actually emit the graphorder callback whenever something
changed, also when a client or port was added/removed.
Also emit the graphorder callback right after a client is activated to
make jackdbus work.
When nothing else is specified, add a default node.link-group property
so that all the nodes from this echo-canceler are tagged as being linked
together in some way.
This allows the session manager to follow the relations between the
different streams and avoids linking those related nodes together, which
avoids playing or recording from itself in a loop.
Fixes#1376
The mempools list keeps track of all allocated mempools but is otherwise
not used. Because it is not protected with a lock, concurrent contexts
or thread loops can step on eachother and crash. Remove this for now
until we actually need it and implement it with some sort of lock.
Fixes#1416
Try harder to get the transport frame_rate from the position.
If we can't find an activation structure, use the configured frame_rate
instead of 0.
Fixes#1432
First calculate the size of the aligned payload and then check if
we can fit this aligned payload in the remaining space in the
ringbuffer.
Otherwise we might be able to fit the item + payload in the remaining
space but then place the alignment bytes at the begginning, which would
break alignment of the next invoke_item struct.
Also check if there is enough space to write the payload bytes.
We check if there is enough space for the invoke_item structure first.
Then we calculate how much bytes we need to use for the payload but we
fail to check if we can actually write that much data, risking
overwriting existing data from the ringbuffer and causing a crash later
when we try to jump to invalid memory.
Add some more comments.
The kernel-provided SCO write MTU is currently never the correct packet
size for writing, so don't try to use it. Some adapter firmware (eg.
BCM20702A0 0b05:17cb) appears in practice sensitive to the alignment of
the msbc frames, and writes with wrong packet size break things but only
on certain headsets. For other adapters, this doesn't appear to matter.
