After upgrading to pipewire 0.3.22, when I joined Zoom meetings my colleagues complained that the audio quality on my end was very bad. They told me when I spoke it sounded very "staticky" and they had a hard time understanding me. So I did a Zoom Test Meeting. The Zoom software had me speak and then played back my audio to me after a brief delay. I could hear a buzzing noise in my recording and it also sounded crackly apart from the buzzing noise (a bit like a cellphone call that is breaking up). My colleagues had never complained about my audio quality before on Zoom meetings, so I downgraded back to the previous version of pipewire, 0.3.18, and did another Zoom test meeting. This time my recording played back very clearly with no discernable buzzing or stuttering.
On a different machine (laptop with built-in camera) I don't experience this issue. The audio quality in pipewire 0.3.22 during a Zoom test meeting didn't exhibit the buzzing or stuttering. I believe the microphone on this machine is also a USB microphone (integrated with the camera), but am not 100% sure. So it may be this problem is at least partly also hardware-dependent.
Could you please retest with PipeWire 0.3.24 that should now be available through Portage? If the issue persists, though, a git bisect will be necessary, which is a bit annoying as Gentoo currently does not have a 9999 (a.k.a. live) ebuild, meaning you'd need to build code from upstream repository. After building the upstream code, stop your current PipeWire instance and run the ./pw-uninstalled.sh . It might also be a good idea to first test known good and bad tags (releases on git) to make sure that the bug is present in upstream as well and not specific to our ebuild. The same, of course, applies for your other PipeWire bug as well. ;)
I tested with pipewire-0.3.24 and this problem is still present. And after downgrading to 0.3.18 it again works fine. The type of USB webcam I'm using is a Logitech QuickCam Pro 9000.
As expected, it's a USB Video Class (UVC) device, so it should share support with just about all modern webcams. It also means that it's unlikely to be an upstream bug as someone should have hit it by now. Right now the best way to proceed might be to attempt obtaining log information from PipeWire. In case of systemd, it should be as easy as examining: systemctl --user status pipewire.service systemctl --user status pipewire-media-session.service I'm not familiar with debugging PipeWire on OpenRC and can only think of this: 1) ensure that /usr/bin/pipewire-media-session is not set to start with pipewire in /etc/pipewire/pipewire.conf 2) killall pipewire; killall pipewire-media-session 3) start pipewire in one terminal emulator 4) then start pipewire-media-session in another 5) optionally start pipewire-pulse for PA emulation and observe any relevant issues they report as well as any differences between how versions 0.3.18 and 0.3.24 react to the USB webcam being plugged in and attempts at using it. Bisecting to find the culprit commit would also work but is of course quite involved, so I can understand if that's not a reasonable option.
Using 0.3.18 as a known-good version, and 0.3.22 as a known-bad version, I bisected the upstream sources. Here is the result of the "git bisect" session: 7f007b6bcad249ce85bfff6f46ceee61e762e27d is the first bad commit commit 7f007b6bcad249ce85bfff6f46ceee61e762e27d Author: Wim Taymans <wtaymans@redhat.com> Date: Fri Jan 8 16:35:26 2021 +0100 resample: tweak the resampler to keep delay number of samples Instead of requiring the upstream node to resubmit the delayed samples, keep the samples ourselves. The benefit is probably too small to measure but it simplifies things a lot. spa/plugins/alsa/alsa-pcm.c | 9 +++------ spa/plugins/audioconvert/resample-native.c | 4 ++-- spa/plugins/audioconvert/resample.c | 11 +++++++---- 3 files changed, 12 insertions(+), 12 deletions(-) Additionally, I found that all of the bad versions I tested spam the console with this warning message as soon as zoom starts running and recording audio from the camera: [W][000083892.218365][alsa-pcm.c:1079 push_frames()] alsa-pcm 0x556756216628: no more buffers None of the good versions produced that warning message while I was doing the bisecting. Notably, also, the warning is emitted from alsa-pcm.c which was modified in this commit. So this definitely looks like the culprit and that the warning is related to the audio quality issues I'm hearing.
I have now also built 0.3.24 but with that offending commit reverted. The warning in the console goes away and the audio is somewhat improved, but it seems there are probably some other changes that have been made since 0.3.18 that are causing additional issues. Now when I do a zoom test meeting using 0.3.24 (with that one commit reverted), I don't hear the buzzing and stuttering that I heard before, but the audio quality is still not good like it was in 0.3.18. It almost sounds like the audio is sped up a little bit, as if some of the samples are being dropped, and occasionally also sounds a little broken up. I'm happy to move this bug report to the upstream bug tracker if it makes more sense to track it there, rather in the Gentoo bug tracker since this certainly doesn't appear to be a problem with the ebuild. Let me know if that's what you'd like me to do.
A web search for that warning message found that there is already an upstream bug report for this problem: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/805 Some folks there reported that they got better results on various master commits, while others indicate the problem is still present. For me the problem is not only still present on master (the latest commit being 34800dc0), but the problem is actually even *worse* on the current master, my recorded audio in a zoom test meeting being more or less inaudible apart from some stray noises. I will report my git bisect findings on the upstream bug.
Great detective work. Thanks for all your effort. I'm not really affiliated with Gentoo in any capacity (as could be seen from me not having an @gentoo.org email or a cool dev tag ;) ), so I can't speak for them, but I magine they'll probably be happy to know it's being sorted by upstream. I hope this issue gets sorted sometime soon. Cheers!
Yes, it's better to forward that information upstream, they will know better how to use it to get it fixed there Thanks!
Upstream has put in a fix in commit 8c334fa3abddc8b6cf797fc5dbeb71282a3a60fe. I'd suggest waiting to stabilize any new Gentoo ebuilds of pipewire until a new release is made with that fix in it. It seems to be a fairly common problem with various models of USB webcams, affecting a lot of people.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b08c84f511f0c75e07bba317ca281a5d9d63ab12 commit b08c84f511f0c75e07bba317ca281a5d9d63ab12 Author: Niklāvs Koļesņikovs <80783143+pinkflames@users.noreply.github.com> AuthorDate: 2021-03-16 22:01:02 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-04-12 21:55:34 +0000 media-video/pipewire: Bump to 0.3.25 & ebuild overhaul This overhaul improves the instructions shown after merging and now provides a sys-auth/realtime-base inspired limits.d file for better user experience. The user ID (UID) range used was chosen to match what SDDM accepts as a valid non-system UID range. This has known shortcomings with very large values in enterprise deployments but this was deemed the least bad of all the imperfect options. Updates SRC_URI to use the official repository hosted by The freedesktop project instead of the GitHub mirror. Patches Meson files to correctly handle docdir per FHS/Gentoo policy. Replaces the old jack IUSE with jack-client for allowing PW to act as a JACK 2 client, while the emulation code is now always enabled, since it has no dependencies nor adverse effects on anything. When systemd USE flag is not set, now automatically enables starting of pipewire-pulse and pipewire-media-session binaries, since most people installing PipeWire will want to do that anyway. Adds instructions to inform users of the change and directs them to Gentoo Wiki with details specific to their setups. Always disables FFmpeg and Vulkan, and removes the respective IUSE, and comments out their *DEPEND, because Vulkan feature is only useful to developers, and FFmpeg code has had no major developments since May 2020 - upstream disables both by default. Removes dead code that no longer was doing anything and correctly adds RDEPEND on supported Bluetooth audio codecs with the associated IUSE flags. As well as adds RDEPEND on sys-libs/ncurses[unicode] that was previously missing and ensures that disabled libsndfile IUSE does not silently disable building of the pw-cat tool, leading to surprising mismatch between upstream documentation and actually installed binaries. Also turns the warning about failed mlock(), that upstream now disables, back on - to known for sure that 256k is really enough for everyone. Closes: https://bugs.gentoo.org/777288 Closes: https://bugs.gentoo.org/777837 Closes: https://bugs.gentoo.org/779058 Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com> Closes: https://github.com/gentoo/gentoo/pull/19965 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> media-video/pipewire/Manifest | 1 + ...pewire-0.3.25-enable-failed-mlock-warning.patch | 12 ++ .../files/pipewire-0.3.25-fix-docdir-path.patch | 32 +++ .../pipewire-0.3.25-non-systemd-integration.patch | 18 ++ media-video/pipewire/metadata.xml | 13 +- media-video/pipewire/pipewire-0.3.25.ebuild | 236 +++++++++++++++++++++ 6 files changed, 310 insertions(+), 2 deletions(-)
Can confirm this is fixed in media-video/pipewire-0.3.25.
