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.
This test currently prevents us from running the test suite in valgrind but
it's not a straightforward fix. So in the meantime, skip this test when
running under valgrind.
Running under valgrind enforces --no-fork so any signal will cause valgrind
to error out, failing the test abnormally. This prevents us from running
our test suite through valgrind, we'd have to mark every test specifically
whether it should run under valgrind or not.
Easier is just to automatically skip tests expecting signals.
