Le jeu. 15 sept. 2022 à 03:21, Ben Hutchings <b...@decadent.org.uk> a écrit : > > I understand that applications with very low latency requirements may > need this sort of performance tweaking. But this is not the normal > case, and PulseAudio hasn't required this. If PipeWire does, I think > that's a serious limitation in PipeWire, and it is not ready for us to > make it the default.
Le jeu. 15 sept. 2022 à 05:35, Felipe Sateler <fsate...@debian.org> a écrit : > > This seems a step backwards to me. Even though pulseaudio also does the > same, the code in question is from an era before rtkit existed. Nowadays, > most users get their RT thread from rtkit. Why isn't rtkit enough for PW? By default, pipewire uses rtkit (without removing its safeguards) and it works perfectly without having choppy sound. In certain circumstances, we need to do some performance tweaking. Now, we have to find the right balance in the pipewire configuration to avoid playing with rtkit safeguards. I am not saying we should bypass rtkit (or remove its safeguards) by default, or even recommend our users to do it. But, if they have a particular use of pipewire requiring the upstream recommendations, we can probably help them and explain them what are the risks. Just a random example [1] where rtkit has limitation for some pipewire uses. rtkit was enough for pulseaudio, but because pipewire goes beyond pulseaudio support for real-time and low latency maybe that is no longer sufficient? But again, we are not talking about a normal use of pipewire. Dylan [1] https://github.com/heftig/rtkit/issues/25
