I think pipewire requires more runtime dependencies. I am trying to make pipewire-pulse working. Without rtkit, it causes quite a few warnings. Reproducible: Always
Not really, the lowest achievable latencies will be higher than with rtkit (obviously) but in my testing they are still comparable to what JACK or PulseAudio provide on the same setup. Not to mention that it's a pure runtime dependency. As a side note, the 9999 can go realtime without rtkit if all occurrences of libpipewire-module-rtkit in configuration are renamed to libpipewire-module-rt and the user is in the realtime group. Not that I recommend doing that but it is possible.
Please review the startup warnings for pipewire-pulse in journalctl without RTkit being present. Hence, I think it is "expected" (similar to the dbus USE="user-session" in #791844 ) May 23 12:55:22 thinkpad systemd[776]: Started PipeWire PulseAudio. May 23 12:55:22 thinkpad pipewire-pulse[133427]: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown May 23 12:55:22 thinkpad pipewire-pulse[133427]: could not set nice-level to -11: No such file or directory May 23 12:55:22 thinkpad pipewire-pulse[133427]: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown May 23 12:55:22 thinkpad pipewire-pulse[133427]: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown May 23 12:55:22 thinkpad pipewire-pulse[133427]: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown May 23 12:55:22 thinkpad pipewire-pulse[133427]: could not make thread realtime: No such file or directory
Yup, I saw those when I was trying to figure out how to make libpipewire-module-rt work as well as when doing the ebuild overhaul and verifying that rtkit is not mandatory. In those log messages the libpipewire-module-rtkit is erroring out but that does not break pipewire itself. And while the performance impact is likely to be system and configuration dependent, no one has ever reported unacceptable performance without rtkit (e.g. audio stuttering due to recurring buffer underruns). If for you or anyone else installing sys-auth/rtkit actually fixed otherwise broken audio, that would be a different story and definitely a valid reason to upgrade sys-auth/rtkit from optfeature to RDEPEND.
I actually (still) have stuttering even with RTKit, but it is likely also Bluetooth related. But consider my report as informative, like you have observed it yourself.
Yeah, Bluetooth, while better, is still a pain point - you likely need to either increase one of the <foo>.clock.min-quantum or api.alsa.headroom configuration parameters. By far the easiest is the default.clock.min-quantum in /etc/pipewire/pipewire.conf but doing so will raise the minimum possible latency for everything. Setting it to 1024 (~21 ms latency at 48 kHz) or less often 2048 (~43 ms latency at 48 kHz) has so far cleared similar Bluetooth issues, and while far from perfect is likely to be comparable to what PulseAudio or JACK can reliably provide with a mainline kernel anyway, so it's mostly a problem for pro audio users that need multiple times lower latencies. At least one Gentoo user was able to figure out how to set it per-device but I don't have have on-hand instructions for that. Also it's worth remembering that PipeWire itself can operate with non-power-of-two values such as 1600 or perhaps more preferably a sum of two adjacent powers-of-two e.g. 1536 (which is 1024+512). One can see the effective configuration in the pw-top tool that comes with PipeWire.
I do think default rdepend sys-auth/rtkit is important. I have been installed and run systemctl --user status pipewire.service everything working great.
For what it's worth, it's possible (but not guaranteed) that Fedora packages may end up switching from libpipewire-module-rtkit to libpipewire-module-rt. In which case I suggest Gentoo to look at how Fedora did it [learn from any issues they had] and consider maybe following them in using RLIMITs instead. This is because RTKit is a double abandonware at this point (the version Gentoo has is a seemingly unofficial fork which itself was abandoned). And some things like flatpaks are not expected to ever be supported by it, nor will it be improved to allow higher priority and longer thread run times - it's a sad reality that some existing JACK applications will get killed, if they aren't allowed to "realtime" for multiple seconds. Finally, I'd like to once more point out that Firefox also has a soft runtime support for RTKit, too. And it would be nice if that was also addresses in a consistent manner.
Bluetooth audio is currently broken without rtkit running. Errors with "br-connection-profile-unavailable". It is at a minimum a hard runtime dep for bluetooth audio use at this time on >=pipewire-0.3.65.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18d85ef89d55d7337b463ff6a04e74b173283589 commit 18d85ef89d55d7337b463ff6a04e74b173283589 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-22 22:47:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-22 22:55:30 +0000 media-video/pipewire: add 0.3.66 Bug: https://bugs.gentoo.org/791847 Closes: https://bugs.gentoo.org/892822 Signed-off-by: Sam James <sam@gentoo.org> media-video/pipewire/Manifest | 1 + media-video/pipewire/pipewire-0.3.66.ebuild | 466 ++++++++++++++++++++++++++++ media-video/pipewire/pipewire-9999.ebuild | 22 +- 3 files changed, 482 insertions(+), 7 deletions(-)
Looks like rtkit not required anymore on new release. Resolved?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=619021553a64bbdd01bda58dbd0858d40b147977 commit 619021553a64bbdd01bda58dbd0858d40b147977 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-22 23:13:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-23 13:23:16 +0000 media-video/pipewire: cleanup elogs, drop obsolete limits file 1. Try to only show messages when they're specifically relevant, either: - new install or relevant USE flag changed, or - upgrading from before a version which introduced changes This reduces noise and makes it easier to see new messages. 2. Drop the manually (ebuild-generated) limits file. This is now handled by the build system. I should've done this last night but overlooked it before bed. Closes: https://bugs.gentoo.org/791847 Fixes: 18d85ef89d55d7337b463ff6a04e74b173283589 Signed-off-by: Sam James <sam@gentoo.org> ...ire-0.3.66.ebuild => pipewire-0.3.66-r1.ebuild} | 233 ++++++++++----------- media-video/pipewire/pipewire-9999.ebuild | 233 ++++++++++----------- 2 files changed, 232 insertions(+), 234 deletions(-)
(In reply to Joe Kappus from comment #10) > Looks like rtkit not required anymore on new release. Resolved? Yeah, I think it's obsolete now we have proper limits handling (thanks to pinkflames handling it all upstream).
