03-16-2021, 07:49 AM
Randomly appearing crackling/popping noises are definitely created by the audio hardware getting suspended whenever it becomes idle for a certain amount of time. Actually, it is the PulseAudio module named "module-suspend-on-idle" that suspends idle audio hardware.
An easy way to reproduce a crackling/popping noise is to open a YouTube video in Firefox and close the browser tab after a few seconds of audio/video playback. After a few seconds, there comes the dreaded crackling/popping noise, as a result of the audio hardware becoming idle and, consequently, suspended.
I had no luck with disabling the aforementioned module in the PulseAudio configuration, which should mitigate the issue. The downside would be increased power consumption. However, for some reason, disabling the module caused either no sound at all, or caused loud hissing all the time. I haven't debugged that further.
Alright, the logical next step is to create a proof of the entire "keep it busy" concept, effectively subverting the aforementioned PulseAudio module. So, let's whip up something simple to keep the audio hardware active all the time; this does the trick:
With this running in the background, I'm yet to hear a single crackling/popping noise, despite trying actively to reproduce the issue. Woohoo!
Surely, this is just a dirty workaround, but it clearly proves that the source of the issue is now properly located. The actual underlining issue is probably an incorrect order in which various components of the entire audio subsystem are powered on and off in the Linux kernel driver. This document provides further information.
I'll probably research this further, aiming at the right solution.
An easy way to reproduce a crackling/popping noise is to open a YouTube video in Firefox and close the browser tab after a few seconds of audio/video playback. After a few seconds, there comes the dreaded crackling/popping noise, as a result of the audio hardware becoming idle and, consequently, suspended.
I had no luck with disabling the aforementioned module in the PulseAudio configuration, which should mitigate the issue. The downside would be increased power consumption. However, for some reason, disabling the module caused either no sound at all, or caused loud hissing all the time. I haven't debugged that further.
Alright, the logical next step is to create a proof of the entire "keep it busy" concept, effectively subverting the aforementioned PulseAudio module. So, let's whip up something simple to keep the audio hardware active all the time; this does the trick:
Code:
aplay -r 8000 -f S16_LE /dev/zeroWith this running in the background, I'm yet to hear a single crackling/popping noise, despite trying actively to reproduce the issue. Woohoo!
Surely, this is just a dirty workaround, but it clearly proves that the source of the issue is now properly located. The actual underlining issue is probably an incorrect order in which various components of the entire audio subsystem are powered on and off in the Linux kernel driver. This document provides further information.
I'll probably research this further, aiming at the right solution.