PULSE_LATENCY_MSEC & PIPEWIRE_LATENCY variables not respected by pulse applications.
If you are filing this issue with a regular release please try master as it might already be fixed.
Version, Distribution, Desktop Environment:
PipeWire 0.3.34; Manjaro (Kernel 5.14); KDE
Description of Problem:
PIPEWIRE_LATENCY
variable not respected by any pulse applications (this is expected behavior, but imo it should be respected).
PULSE_LATENCY_MSEC
variable not respected by any pulse applications (this is unexpected behavior)
Additionally
pipewire.conf
default.clock.min-quantum = 1024
Is also not respected by at least some applications, I feel like unless explicitly set in pipewire-pulse.conf, the pipewire.conf setting for min-quantum should overrule the default for pipewire-pulse if the pipewire.conf setting is higher than the default for pipewire-pulse. This is for user friendliness reasons.
pipewire-pulse.conf
pulse.min.quantum = 1024/48000
Is respected however the clock rate part of that setting seems to be ignored (e.g. clients are sometimes playing in 44.1khz instead of 48khz; this is probably related to the default.clock.allowed-rates = [ 44100 48000 96000 ]
I have set in pipewire.conf, maybe it overrides this? I actually don't care about that part of this setting (I don't even think it should be part of this setting, clockrate should be it's own setting) so it's irrelevant to the issue)
How Reproducible:
100% in all my attempts
Steps to Reproduce:
- Run pw-top & monitor QUANT for each application launched
- Launch a pulse application to see default latency
- Launch same pulse application with
PULSE_LATENCY_MSEC
- See latency unchanged according to pw-top.
Actual Results:
No extra latency/Buffering
Expected Results:
Extra latency according to PULSE_LATENCY_MSEC
variable setting.
Additional Info:
I further know for certain this setting is not being respected because I have 3 applications that have issues unless the beffer size is at least a certain size. 2 of them have an audio buffer setting I have set to 2048 (this translate to QUANT 2048 in pw-top, and reads as 0.04s latency in easyeffects). When that audio buffer setting is set the issue goes away, however when I use the default buffer setting and instead set PULSE_LATENCY_MSEC
(to 60), the issues are still present, QUANT shows same as default (e.g. without variable set) as 1024/0.02s and the issues that should be getting solved thanks to this setting are still present.