After upgrading to Pipewire 0.3.72-1 on Fedora 38, audio input (at least from a microphone) has significant delay (approximately 1.6 seconds). This is noticeable in the visualiser in Gnome sound settings, as well as in Discord (flatpak), and on https://www.onlinemictest.com/ inside Firefox 114.0.2-1.fc38. Downgrading pipewire (sudo dnf downgrade pipewire --allowerasing) to 0.3.67-1 and restarting pipewire (either the full system or via systemctl) stops this from occurring. Reproducible: Always Steps to Reproduce: 1. Have the specified version of pipewire and associated packages installed. 2. Use an application that takes mic input, and responds visually to that input. 3. Speak into the microphone. Actual Results: There is a delay (approximately 1.6 seconds) between speaking into the microphone and the application responding. Expected Results: Minimal delay between input and response. My microphone is a Presonus Revelator Dynamic USB-C, which has worked perfectly with Linux until this update; I originally thought it was an FX preset I'd messed up in Presonus' windows software. I will attach pactl logs etc as attachments. Any other useful logs, let me know and I'll get them to you.
Created attachment 1973035 [details] Output of pactl info.
Created attachment 1973036 [details] Output of journalctl --user -u pipewire. Output of journalctl --user -u pipewire for boots from today. Multiple restartsq are me swapping version to test that downgrading fixes my issue.
what is the output of pw-top? can you attach the output of pw-dump when the problem is happening?
Created attachment 1973206 [details] Output from pw-top
Created attachment 1973207 [details] Output of pw-dump.
Tested today - Same bug still occurs in pipewire 0.3.73-1.fc38.
Tested again today, still occurs in pipewire-0.3.74-1.fc38.
Tested today, still occurs in 0.3.75-1.fc38. Are there any configuration changes I can make to give you more information? And is it worth compiling pipewire locally, or is the fedora build "stock" enough that it shouldn't make a difference. I suppose that sticking on an old version isn't too much of an issue for now, but I'm worried that at somepoint a security update will be released and I won't be able to update to it due to this bug.
I am pretty sure that this is caused by the use of hires timestamps and the driver is not giving accurate timestamps. You could check this theory by setting api.alsa.htimestamp=false on the node properties of the hardware nodes: https://pipewire.pages.freedesktop.org/wireplumber/configuration/alsa.html#node-properties There seem to be other people suffering from this bug, I might disable hires timestamps by default in future versions.
Evening Wim, Thanks for that, I have added a rule to set that in the config and it now seems to work. Much appreicated.