There appears to be a driver or configuration glitch with input on my main audio card. The problem only affects the integrated motherboard audio (Starship/Matisse HD Audio Controller Analog Stereo) with my headphone microphone plugged into the front panel: When using my USB webcam as the capture device I experience no issue.
Essentially sound does come through the microphone, however the recorder begins to lag when using it. This is even visible on the capture waveform or volume bar which are only updated in slow increments with huge delays. The audio captured is a garbled mess: It does correspond to noises received by the microphone at various points in time, but it’s as if the whole thing is fast-forwarded and you only hear a bunch of absurd noises.
This doesn’t happen quite all the time: On rare occasions capturing through this microphone works just fine, but after the first attempt this lag is introduced and it becomes unusable. At first I only experienced the issue when recording sound in Audacity, now I’m also having it occur in Discord and other voice chat applications.
Anyone know what can cause an input device to do this? I played with the settings in Pavucontrol but nothing seems to make it go away. Intuition tells me it might be related to buffer overflow and the device being overwhelmed by something, in which case I may need to hack some latency setting.
As you didn’t post an inxi --admin --verbosity=7 --filter --no-host --width, we can only guess, but my first port of call would be a real-time (RT) kernel.
Use the kernel GUI program or the mhwd-kernel CLI program to install an RT kernel and grub options to boot in said kernel and see if the lag goes away…
If yes, Solution
If no, report back with some more info (Using an RT kernel?)
How does a realtime kernel help? To be fair I’m actually not familiar with what that is, I think I heard the name but need to look it up again. But as far as the kernel goes I’m using Linux 5.11.14-1 (latest stable). And here’s the output of that command:
Also a little update: I found some threads for Arch Linux of someone else seemingly addressing the same issue, including a section in the docs about it.
It seems to require playing with some core configs so I may try this one later. It’s possible the default fragment count / size for Pulseaudio is too demanding for certain hardware. The documentation suggests disabling timer-based scheduling via tsched=0 in /etc/pulse/default.pa
Today I tried changing all of the settings in those articles I shared. Unfortunately none of the countless modifications I tried in /etc/pulse/* (followed by restarting pulseaudio obviously) fix the microphone issue. I have no idea what’s triggering this particular input device to lag and cause total garbling.
I’m not trying pipewire yet as that sounds like a major change which might break my system. If it’s a replacement for pulseaudio I’d rather use it automatically once it’s stable enough that distributions switch to it by default. Same as the X11 versus Wayland conundrum.
I suspect it must be some kind of driver issue anyway. It feels like this goes beyond PA.
I uncovered an interesting clue today. It appears that once I open up Audacity which causes the microphone to break, restarting Pulseaudio will NOT unbreak it: The microphone remains glitched system-wide until I restart the machine. I could confirm this by using arecord / aplay before and after using Audacity and restarting Pulseaudio, before it records great and after it’s still garbled.
I just now, finally, found another thread where someone else is discussing this exact issue: It started to feel like I was the only one on the planet getting it! The reporter is also using Manjaro… wonder if they’re also on this forum so we could discuss it here as well.
Tried more things today but no success: Not even logging out and back in or restarting not just pulseaudio but alsa itself (via alsactl command) can bring back the mic, only a full system restart will. This makes it hard to even test which setting in Audacity could be influencing the problem, I have to do a full restart each time I run it before it’s triggered beyond repair.
If anyone has more data that could help please share it: I’ve been trying for two years to get this fixed, from openSUSE and now into Manjaro. There most be a logical explanation somewhere.
This thread should have been closed in April 2020. You were given sound advice ─ no pun intended ─ but you chose not to follow through. Such is your prerogative, but then you should have abandoned the thread instead of bumping the thread every couple of months.
That constitutes abuse. I am therefore closing the thread.
