Bill in Co wrote:
A puzzling audio problem on one of my laptops: I noticed the windows sound
events all sounded lower in pitch than normal (guessing about 3% or 4%
lower)
on this Dell e6500 laptop. So I copied some of the sound events over to a
temp
folder, and played them using various wav players, and sure enough, they
all sound lower in pitch (with the exception of one wav player, which
renders
the pitch correctly). I think I have finally noticed one thing unique about
this: these windows event sounds are mostly 22.05 kHz, 16 bit wave files,
not the
standard 44.1 kHz. Sitll, they should all play with the correct pitch!
I've got the up-to-date IDT audio driver, so that's apparently not the
issue.
This Dell e6500 uses a IDT High Definition Audio Codec (whether I like it or
not). I was hoping to find some other alternative audio codec that might
work
better (assuming that codec is related to this problem), but I haven't found
any alternative (on the Dell drivers site, and they are all listed there).
How this can happen is puzzling to me, however, and short of getting some
alternative audio driver(s), I don't see an obvious solution, unless I'm
missing
something. It's not the end of the world, but I'd sure like to know if I
can
rectify it, or if someone has some suggestions. As I said, everything is
hunky dory in Device Manager and all drivers are up to date. What is also
interesting is that one really simple player (called Billy Player) plays the
pitch correctly, but the others do not.
Maybe it means there is some overhead in decoding non 44.1 kHz audio files
on this system, causing some latency? But that just seems too far out to
me. Besides which, Billy Player says it's using the IDT audio and it plays
it correctly.
Any ideas? TIA.
In Audacity, record a reference sine wave tone in a waveform.
Say, 440Hz.
Play it back.
Pass the signal to a second computer for recording.
See if the ratio is 44100/48000 , implying some driver
is using the wrong sampling rate for something. Audacity has
an FFT display, which can show the frequency of spikes
in the frequency domain graph.
As far as I know, sound is managed by "keeping a buffer full".
That means, to play a sample, the hardware is set to a nominal
rate. If the buffer drops below a threshold value (like, "half full"),
an interrupt is issued, and the sound subsystem loads a bit
more stuff into the buffer. The processor itself isn't
really metering the flow. You would think the sound
subsystem could underflow, be data starved, and have
to repeat samples (create a flat spot in the waveform
at some point), but I suppose it's a function of the
source. For playback of music, it just means the
entire composition finishes sooner. For video playback,
with a video and audio sound stream, there's likely to
be some other sort of pacing method.
If it was a crystal timebase reference problem, that's
probably good to 100ppm. And I don't know if human pitch
sensing can detect that small of a shift.
https://en.wikipedia.org/wiki/Pitch_(music)
"Below 500 Hz, the jnd is about 3 Hz for sine waves,
and 1 Hz for complex tones; above 1000 Hz, the jnd for
sine waves is about 0.6% (about 10 cents)."
Which suggests you cannot hear 100ppm of error.
But 48000/44100 or about 9% error caused by a sampling
rate setting error in a driver, you could hear that.
A number of sound chips are inherently 48000 sampling
rate, and some other rates are done by resampling
or something.
In any case, the purpose of recording the output of
the defective setup, is to note whether the error
is "exactly 9%", if you get my drift... In other
words, it's a known issue with the sampling or
resampling going on in some chips and their
drivers. If the error was some other weird ratio
(suggestive of a broken quartz time base), then
you'd have to come up with a new theory to explain it.
On your "measurement machine", the chip may offer a
192KHz sampling rate. But this doesn't mean it can
properly reproduce a 96KHz sine wave (Nyquist).
The input filter (let's pretend it's an RC low
pass filter) is set for around 50KHz or so.
Frequencies higher than that can be severely
attenuated. But, using the 192KHz sampling rate
doesn't hurt the time domain measurement capability.
By using the high sampling rate, you may improve
the pitch measurement accuracy. That's assuming
the chip on the second computer isn't doing
something stupid too :-)
Here's an example of me checking Audacity 440Hz
on the other machine, by using Audacity on this
computer to record LineIn. On the source Audacity,
the "Generate" menu produces a 30 second 440Hz
tone by default. And I've recorded that on this
computer, then done an FFT on it.
https://s15.postimg.cc/5brhkzb63/Lin...other_comp.gif
Paul