On Wed, 17 Mar 2021 at 11:37, Olivier Langlois via arch-general <arch-general@xxxxxxxxxxxxxxxxxxx> 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_790489 * 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
