This is a strange thing I've noticed across several different computers.
When I have a console session open, every time I scroll (say in a pager) there's a faint click for every line that goes by. It becomes more noticeable if I continuously scroll. Muting my laptop's speakers has no effect.
Is this by design, or some strange quirk?
This is likely interference from the CPU power supply traces.
I particularly notice this in cases where there is a CPU governor that changes it's clock speed depending on load. The buzz you hear is actually the frequency at which the governor is changing CPU speed.
I recall an old laptop where the sound was not just audible in the 'phones, it actually manifested as a buzzing noise from the motherboard. For a while it was possible to suppress it by disabling SpeedStep and running the CPU at full clock speed all of the time, but eventually it was near constant, and I had to get the motherboard replaced for fear of losing my sanity.
These days I notice interference in my 'phones when the CPU load changes dynamically - when loading games in particular (bursts of CPU activity as it processes resources, followed by pauses as it waits for buffers to fill from the disk). It's more obvious when the headphones are plugged into the front panel of my desktop than the rear, which reinforces the idea that it's electrical interference ; the traces for the front panel are closer to the CPU, possibly. I plug my phones into the rear sockets which seem to be better shielded.
You might find that you get some relief by enabling the "spread spectrum" controls in your BIOS - these controls adjust the timings of internal system clocks to make the square edged waves less harsh and are designed to generate less interference. As noted in the article, spread spectrum is often disabled in overclocked systems to help prevent clock skew, but these features are usually enabled by default. You probably won't find these settings on a laptop BIOS though.
The other technique I use for combating this is to reduce amplifier levels. The alsamixer terminal application is useful here for finding all the relevant levels, some of which can be hidden in the GUI mixers. Dropping them all out of the red zone to about 80% means that the initial interference is amplified less and becomes inaudible. This also makes listening to music on my Windows laptop bearable - reduce the master volume to about 30%, rather than the Wave volume, and the interference disappears. This also reduces clipping on some hardware.
Not sure since the internal speakers should be turned off by default but if this is the sound made by the internal speaker of your system you can turn this off with several methods.
with
xset b off
xset b 0 0 0
xset is a user preference utility for X. The b option controls bell volume (1st 0), pitch (2nd 0) and duration (3rd 0) in milliseconds.
You can also change this by editing ~/.inputrc (single user) or /etc/inputrc (global)
set bell-style visible
to change it to flashing and
set bell-style none
to turn system beeps off.
You can also blacklist the module
sudo vi /etc/modprobe.d/blacklist.conf
and add
blacklist pcspkr
On my system number 3 is already set as default so I would expect this to be so on your system too. This also seems to be the default method to turn system speaker off.
pcspkr is responcible for system beeps so this is not about the speakers that deal with your sound settings. Muting the speakers does not mute the system beeps.
I've encountered something similar on some of my older desktop PCs and, as far as I could tell, it had to do with devices being set up to share IRQs without actually being able to play well together.
Given that one of the systems made a clicking noise every time I rolled the scroll wheel while the system was under any kind of non-trivial load, they may be the same thing. (The problem tended to be some form of "input from the keyboard/mouse causes clicking on the audio output" when I encountered it on various PCs)
In my case, fixing the problem was as simple as toggling the "Plug-and-Play OS" setting in the BIOS. That changed which IRQ assignments were done by the BIOS and which by Linux and, in turn, altered IRQ assignments enough to resolve the conflict.
