On Wed, 17 Mar 2021 at 11:37, Olivier Langlois via arch-general <arch-general@lists.archlinux.org> wrote:
The glitch that you hear is the symptom of the sound card interrupt not delivered in time.
Thanks for the reply. So do you think in the case of bluetooth, it's the BT controller that doesn't receive the interrupt in time?
You can validate this symptom by using the ALSA command line tools such as aplay.
The interesting thing is that aplay appears unaffected. See some discussion here: * https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1122#note_7904... * https://bbs.archlinux.org/viewtopic.php?id=262706
You would see the error about an underflow each time that you hear a glitch.
I see errors in pulseaudio and pipewire logs, but nothing in kernel logs.
Usually, it is caused by a badly written driver that is masking the interrupts for too long.
Yes, I reached the same conclusion, but given that it seems to go away when the discrete graphics card is operating at full power, I figured it was something to do with the card reacting slowly to messages on the PCI bus.
Even if the driver is masking locally the interrupts on a single core, it will end up putting all the system interrupts to a stall because of the round-robin interrupt balance algo, they will all end up on the masked core pretty fast.
Thanks; that's helpful information. How could I go about diagnosing this? I'm not sure what to look for in /proc/interrupts, for instance.
If possible, try to switch drivers from Nvidia to the open source one. As a workaround, you may explore the option to pin your sound card to a specific core to see if it helps.
I can't really switch to nouveau, as I do use the discrete graphics (with PRIME). I do at least have a workaround, which is something. Thanks again for the reply, Paul