The commit cited below mistakenly removed the set_rlimit call from under
`if (impl->use_rtkit)`, saying it doesn't have an rtkit implementation.
However, this function does call rtkit, so it has to be called in the
rtkit flow, otherwise pipewire fails to set the realtime priority,
printing the following error message:
mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
mod.rt: could not make thread #### realtime using RTKit: Permission denied
Fixes: 5ae1c03d77 ("module-rt: small fixes")
When a client writes more then requested, let the requested field go
negative so that it is taken into account the next time we ask for more
data.
Also the requested field follows the difference in the write pointer
caused by seeks.
See #2626Fixes#2674
A client can sometimes send more data than we requested. PulseAudio
keeps the extra data around, it just asks for more data when it consumed
some of it.
PipeWire however always tries to keep tlength worth of data, as
specified in the PulseAudio docs... Keep track of how much extra data
has been sent and keep this around as well. Make sure we flush this
extra data as well.
Fixes#2626
Move the latency fraction calculation to fix_ functions so that the
new latency rate can be used when creating the streams.
Actually set the requested record attributes on the stream instead
of modifying the defaults.
See #2671
3f6fe392 uses headers from /usr/include/lv2/atom/. but this leads compilation
failure for some distros (i.e. ubuntu 18.04) as they have some
different location for these headers. One can find these headers
at /usr/include/lv2/lv2plug.in/ns/ext/atom/ (for ubuntu 18.04)
instead /usr/include/lv2/atom/. So guard them with __has_include.
and mention other possibilities.
Fixes#2670
PulseAudio configures half of the fragsize as the source latency. It
also sends chunks as soon as they become available.
This means that we also need to configure the source with half of
the fragsize latency and send in chunks of fragsize/2. Keep this in
the unused (for record) minreq field.
could_use_rtkit -> can_use_rtkit.
Only warn when setting nice and there is no rtkit fallback.
Always call set_rtlimit, it does not have an rtkit implementation, if just
has some properties with limits.
Only try to set nice again with rtkit when we required rtkit for some
functions.
Previously module-rt only checks if the user have the permission to use
realtime scheduling, and will unconditioally disable RtKit if they do,
even when they don't have the permission to set nice or rlimit.
Support fork-free readiness notifications.
Without this, a service supervisor that does not implement socket
activation has no way of knowing whether or not pipewire is ready to
accept connections on the socket.
s6 is the most popular service manager that supports this mechanism.
See here: https://skarnet.org/software/s6/notifywhenup.html
At the moment, cross compilation may not work in certain cases because
checks are carried out against the build machine instead of the host machine.
Replace uses of `build_machine` with `host_machine` to fix that.
In native compilation, all three "machine objects" available in meson
are the same, so this change should have no effect in that case.
More: https://mesonbuild.com/Cross-compilation.html
Init the compat types map a little earlier so that it is initialized
when we try to clear it on error.
Add the client listener earlier so that we can use the events to clean
up the map, source and connection.
Some Flatpak apps want to manage sound fully (change default outputs,
move streams from other applications). Real Pulseaudio always grants
full permissions, but pipewire-pulse doesn't, which breaks some
applications, e.g. Zoom.
Work around this by granting the manager permission if the application
also has devices=all access.
To do things properly, this probably should use the Portal media roles,
but this would need further work elsewhere.
When the stream has more channels than the filter inputs or outputs,
don't try to connect an invalid filter port but ignore the input and
clear the output.
pthread_getschedparam() always returns non-negative values, so checking
if its return value is less than zero always evaluates to false.
Also, pthread functions don't set errno. While logging a warning
message, use the return value of pthread_getschedparam() instead of
errno.
