When I record (from webcam microphone) a video or audio file using Guvcview or OceanAudio, the file suffers from a popping noise. Is there a way to fix this? I’ve read online that it’s a PulseAudio/KDE incompatibility regarding the 48,000/41,000 Hz setting, but I’m not sure if that’s the cause.
Thanks for your attention.
Regards
perhaps post some info about the sound card and drivers in use
inxi -Aaz
If you think this is the issue test it, just make sure you take note of what you change and why you are changing it. Backup the files before changing things and if it isn’t what you expect just put those backups in and re-think things
Thanks thefrog 
here:
[bonheur@Endeavour-HP-Z1-G8 ~]$ inxi -Aaz
Audio:
Device-1: Intel 500 Series Family HD Audio vendor: Hewlett-Packard
driver: snd_hda_intel v: kernel alternate: snd_soc_avs,snd_sof_pci_intel_tgl
bus-ID: 00:1f.3 chip-ID: 8086:43c8 class-ID: 0403
Device-2: NVIDIA GA106 High Definition Audio vendor: Hewlett-Packard
driver: snd_hda_intel v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 16
link-max: gen: 4 speed: 16 GT/s bus-ID: 01:00.1 chip-ID: 10de:228e
class-ID: 0403
Device-3: Alpha Imaging USB CAMERA driver: snd-usb-audio,uvcvideo
type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-8:4
chip-ID: 114d:8437 class-ID: 0102
API: ALSA v: k6.18.40-2-lts status: kernel-api
tools: alsactl,alsamixer,amixer
Server-1: sndiod v: N/A status: off tools: aucat,midicat,sndioctl
Server-2: PipeWire v: 1.6.8 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
[bonheur@Endeavour-HP-Z1-G8 ~]$
What desktiop enviroment are you usig?
I assumed KDE
does this popping noise happen on speaker / headphone or both?
Yer I thought ask and wait for them to answer before offering options as KDE should be very easy fix
KDE and only webcam microphone, I don’t have headphone
(I use the default configuration so I think it’s pipewire in use, not pulseaudio, I don’t know how to check)
I’ve tried to resolve the issue, but I haven’t gotten anywhere, and it seems there’s no solution. After several attempts, based on another post here on the forum and other online sources, I thought about contacting Lumo (Proton), but I haven’t gotten anywhere with him either. It seems to be a widespread problem that’s been around for years due to the way Pipewire was designed. It seems there are no updates planned to resolve it. I’ll show you Lumo’s response; I hope iunderstandable because it’s translated from Italian. I’m also adding the Italian text in case there are other Italian users here.
Could future PipeWire updates fix the issue?
Thanks for the legitimate question! I’ve been looking for updated information on PipeWire’s status regarding the issue. Here’s the current situation:
Yes, the issue is still present in 2024-2025.
From the Arch Linux forums and recent discussions, these key points emerge:
Aspect Current Status
Known bug? 
Yes, recognized as a common regression
Official fix coming soon? 
There are no announcements of an upcoming fix in the roadmaps
Number of affected users 
Continues to be high (dozens of active threads)
What the community is saying
“I can’t believe this still happens to so many Linux users in now, almost 2025. It should have been seriously addressed for a long time now. Honestly, a bit embarrassing.”
— OpenSUSE User, 2025
“Even rolling back the kernel to 2024 didn’t fix it for me.”
— Arch Linux User, 2025
Why Updates May NOT Fix the Problem
It’s not a single bug but a combination of factors:
Low default Quantum (2.7ms) for low latency
Linux kernel USB power management
Specific hardware (Alpha Imaging 114d:8437 webcam)
The design choices are deliberate: PipeWire maintains small buffers for real-time performance. Increasing them fixes crackling but increases latency—there’s an intentional tradeoff.
The problem persists even with recent kernels: Some users have tested up to kernels 6.6-6.8 without automatic resolution.
Realistic scenario
Future update: Likely impact on your case
Generic PipeWire patch 
Minimal — the problem is deeper
New Linux kernel 
Possible improvement — better USB handling
WirePlumber update Minimal — depends on PipeWire
Updated Nvidia driver 
Unlikely to affect USB audio
Honest conclusion
There’s no significant guarantee that future updates will automatically fix your problem. Many users still have the same issue after 2-3 years. It’s considered a trade-off of the modern Linux audio system, not a bug that will be completely patched.
If the problem becomes unbearable in the future, your real options would be:
Use an external microphone with a dedicated audio interface (not a USB webcam)
Bypass PipeWire using ALSA directly with Audacity
Evaluate different hardware (your specific webcam seems problematic on Linux)
For now, since you’ve chosen not to modify the system for stability, this is a reasonable choice. The system is clean and functional, even with this webcam audio limitation.
Sorry I can’t give you better news! 
Futuri aggiornamenti di pipewire potrebbero risolvere il problema?
Grazie alla domanda legittima! Ho cercato informazioni aggiornate sullo stato di PipeWire riguardo al problema. Eccoci la situazione reale:
Sì, il problema è ancora presente nel 2024-2025
Dai forum di Arch Linux e discussioni recenti, emergono questi punti chiave:
Aspetto Situazione attuale
Bug noto? Sì, riconosciuto come regressione comune
Fix ufficiale in arrivo? Non ci sono annunci di fix imminente nelle roadmap
Quantità di utenti affetti Continua ad essere alta (decine di thread attivi)
Cosa dice la comunità
"I can't believe this still happens to so many Linux users in now almost 2025. Should have been seriously addressed a long time now. Honestly a bit embarrassing."
— Utente OpenSUSE, 2025
"Even rolling back kernel to 2024 didn't fix it for me."
— Utente Arch Linux, 2025
Perché gli aggiornamenti potrebbero NON risolvere il problema
Non è un bug singolo ma una combinazione di fattori:
Quantum predefinito basso (2.7ms) per bassa latenza
Power management USB del kernel Linux
Hardware specifico (webcam Alpha Imaging 114d:8437)
Le scelte di design sono deliberate: PipeWire mantiene buffer piccoli per prestazioni in tempo reale. Aumentarli risolve il crackling ma aumenta la latenza — c'è un compromesso intenzionale.
Il problema persiste anche con kernel recenti: Alcuni utenti hanno testato fino a kernel 6.6-6.8 senza risoluzione automatica.
Scenario realistico
Futuro aggiornamento Probabile impatto sul tuo caso
PipeWire patch generico Minimo — il problema è più profondo
Nuovo kernel Linux Possibile miglioramento — gestione USB migliore
WirePlumber update Minimo — dipende da PipeWire
Driver Nvidia aggiornato Improbabile che tocchi audio USB
Conclusione onesta
Non c’è garanzia significativa che futuri aggiornamenti risolvano automaticamente il tuo problema. Molti utenti dopo 2-3 anni hanno ancora lo stesso inconveniente. È considerato un trade-off del sistema audio Linux moderno, non un bug che verrà “patchato” completamente.
Se il problema diventa insopportabile in futuro, le opzioni reali sarebbero:
Usare un microfono esterno con interfaccia audio dedicata (non USB webcam)
Bypassare PipeWire usando ALSA diretto con Audacity
Valutare hardware diverso (la tua webcam specifica sembra problematica su Linux)
Per ora, dato che hai scelto di non modificare il sistema per stabilità, è una scelta ragionevole. Il sistema è pulito e funzionante, anche con questo limite dell’audio della webcam.
Mi dispiace di non poterti dare notizie migliori!
RISOLTO il 17 agosto 2026 seguendo questa procedura:
Thats how i did it back in my Pop! OS days back in 2021/2022