When it comes to sound problems here, I sometimes debug them by
connecting the output of one computer, to the input of another.
Then, I can make a recording with the other computer, and look
at the kind of distortion of the waveform.
Then, it is a matter of trying various stimuli, on the source
computer, to make it easier to spot the distortion as recorded
by the other machine.
I might use Audacity to play sounds, and Sound Recorder to record
the same signal as goes to the speakers.
To detect echo problems, I use a trapezoidal pulse.
I might have Audacity create a 440Hz sine wave, when it comes to
waveform (the recorded waveform is not all perfect sine waves),
that tells me the sound chip is suffering data underruns and is
forced to output the "old" voltage value for multiple sample
If your data is being corrupted somehow, such that an audio value
of 0x00 ends up as 0x80 when it hits the speakers, that causes
a huge "spike" in the output, and it is quite easy to tell that
apart from the flat waveform type. That can give a deafening
than ticks or static from data underruns.
So part of the fun of fixing sound, is deciding what kind of problem it is.
With the right kind of input waveform, the distortion will stand out.
Assuming it is the underrun kind, we have already covered "Delayed Transaction"
and "PCI Latency" setting. The first one, cures "slow" bus cycles. The second,
if dialed down, prevents bus hogging during DMA (so all the cards get a chance
to DMA at regular intervals).
Other possible explanations, might include IRQ priority (on an older system
with PIC interrupts). Your system is a bit too new for that kind of thing.
I think my first computer was influenced by the IRQ, but the effect was so
slight, it might have been a placebo effect.
Another thing you can check, and can be a problem on modern systems, is
DPC is a deferred procedure call. it is only claim to fame in this case,
is that it allows a person to monitor whether the computer is taking any
unintentional "naps". Otherwise, we would not really care about this.
If the system takes a "nap" when the sound chip needs to be serviced
and given data, that can cause noise in the audio.
The DPC is timestamped, such that it is possible to figure out how
long it sat in the queue before being serviced. The time should be quite short,
in the microsecond range. DPCs were used, to complete interrupt service
routines, but at user level.
And this program, graphs the service time for the current DPC.
So if a DPC is serviced in microseconds, the graph remains low.
If the system is non-responsive for milliseconds, that makes
a big spike in the graph. Systems with spikes in the graph,
are no good for recording studio applications.
It might cause "ticks", if your result looked like this.
Now, one way to upset things, is if Cool N' Quiet is enabled. In an
Anandtech review, they noticed that video playback was slightly
smoother, if CNQ was disabled. And this was caused by the processor
changing P-states, many times a second. And that was happening, because
the time constant of bursts of computing activity for video playback,
happened to cause CNQ to switch P-states a lot. They got better
results by switching it off.
A second way to steal time from a system, is with SMM. SMM stands for
System Management Mode, and is a way for the BIOS to run code while the
OS is running. Intel invented this scheme. If the BIOS asserts an SMI,
the processor halts what it is doing, and switches over to running the SMM
code (which is BIOS code). An SMM is not supposed to run for very long,
because if it did, it would affect time keeping on the OS.
A couple Gigabyte motherboards, possibly with Intel processors on them,
had DPC "spikes" in the graph the above tool makes. And it was a BIOS problem.
Once Gigabyte was informed their SMM code was running too long, they
issued a new BIOS with it fixed. SMM code is sometimes used to adjust
the number of running phases on a fancy VCore switching converter.
it is a gimmick that claims to save wall power, by only using as
many phases as are necessary to generate VCore.
So to test, you download and run DPCLat, then look at the graph.
It is OK to have the occasional spike - for example, if I start
a 3D game, there is a *huge* spike when the video card switches
to 3D mode. But that is to be expected, because a lot is happening
at driver level at the time. And if textures are being loaded,
the DMA transfer at 4GB a second the video card can be doing,
can make a dent in the system for a fraction of a second. So if
you see the occasional spike, it is not the end of the world.
But if you see a repetitive pulsing, you would want to track that
down. On an AMD system, you can disable Cool N' Quiet and see
if anything changes.
When it comes to SMM mode, there is not much you can do there,
except try another BIOS version. With pre-built computers, many
of them never receive a second BIOS (i.e. any kind of update),
so that is not an option.