On Thu, 8 Apr 2004 18:14:02 -0400 stan <[EMAIL PROTECTED]> wrote: >On Wed, Apr 07, 2004 at 02:48:59PM -0400, Chris Metzler wrote: >>On Wed, 7 Apr 2004 12:04:43 -0400 >>stan <[EMAIL PROTECTED]> wrote: >>>On Tue, Apr 06, 2004 at 11:38:16PM -0400, Chris Metzler wrote: >>>>On Tue, 6 Apr 2004 15:43:30 -0400 >>>>stan <[EMAIL PROTECTED]> wrote: >>>>> >>>>> 've swaped teh CPU on a Debina machien, and now my MP#'s play at >>>>> the wrong ptich, like a tpe played at a speed slower than it was >>>>> recorded. >>>>> >>>>> Where do I need to look to troubleshoot/fix this isue? >>>> >>>> Are you sure it's just MP3s? If you play back e.g. a .WAV (PCM >>>> audio), does it also play back with the wrong speed? >>>> >>> That seesm likely. I have not tried it, but my suspicion is thta the >>> problem is common to all DAC. >>> >>> Given that, where should I strat looking? >> >> Can you try it? Maybe dload a .wav from somewhere on the web and >> play it and see what happens? I'd hate to spend a lot of time >> thinking about it and then find out I was barking up the wrong >> tree. > > OK, I was able to confirm that a .wav filed played with the "play" > command also plays at the wrong tempo. > > Where should I start looking for the problem?
I'm assuming that the .wav file you tried was one you fetched
from some other machine -- that is, it wasn't created on your
machine, from decoding an MP3 or something like that.
OK, there are two possibilities that occur to me.
The first is that your PCM output is passing through some application
layer that rebuffers the data and sets a new (smaller) rate, before
going to the soundcard. JACK can do this, as can an ALSA rate plugin
device defined appropriately in your .asoundrc. But I doubt this
is the problem. For one thing, you said that this began immediately
after a CPU change; that wouldn't effect software configuration, of
course. The other reason is that configuring JACK this way (a
*slower* rate) isn't its default; ditto with ALSA. So that means
that you'd have to have set it up yourself, which in turn would
imply that you'd know about it.
So a second possibility is that your soundcard's DACs just aren't
being clocked at the appropriate rate. I don't know whether
soundcards typically (and yours in particular) get their clock from
a timer on the card, or whether they derive it from the PCI bus
clock in some way. If the former, then you may have a bad soundcard
now, since I know of no way to fix a bad timer on a soundcard. If
the latter, then it's possible that if the PCI bus isn't being
clocked correctly, the soundcard's DACs won't be either. In this
scenario, the soundcard would have circuitry that implements this
scheme: "OK, I'm supposedly getting 66 MHz off the PCI bus, so if
I pull every 1512th signal, I'll get a 44.1kHz clock" or whatever.
I don't know for sure that that's how it works, but something like
that. Anyway, if the PCI bus timing *isn't* at 66MHz, but is at
some slower rate, the soundcard's attempts to build clocks (in response
to the rate information it's told the incoming PCM data is at) will
produce a clock that's too slow.
This also makes sense in the context of what you say happened. The
A7V boards (if my A7V333 is representative) are shipped to use BIOS
for timing, and the BIOS can determine what the appropriate timing
is based on the CPU present and motherboard. If you put in a CPU
beyond spec for that motherboard, maybe it's possible that a bad job
was done of this timing adjustment, and similarly on the way back
after you put in an appropriate CPU? I dunno.
So what I'd do now is look at all the sources of timing information
about your machine. You said you have an ASus A7V133. If it's
anything like the A7V333, you'll need to look at both
motherboard jumpers/dipswitches AND BIOS settings to see how your
machine is currently configured. On my A7V333, there are dip
switches to set FSB speed and multiplier, as well as jumpers that
determine whether the board should get its timing info from the
jumpers/dipswitches or whether it should get it from BIOS. Collect
this info and see if the multiplier and FSB speed (in particular)
make sense. Maybe the multiplier and FSB speed ended up being
adjusted in such a way that the CPU is being clocked at the
correct speed, but the motherboard (and thus PCI bus) isn't (FSB
speed too low, multiplier too high). lspci -vv may also give
you info, but I don't know if the speed information it provides
is what the devices on the PCI bus *want* to be clocked at, or
are actually being clocked at.
Assuming that this is the problem, you might need to set the
correct timings by hand, either through adjusting the appropriate
BIOS settings manually, or by bypassing BIOS timing altogether
and using jumpers/dipswitches on the board to set things properly.
Let us know . . .
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
pgp00000.pgp
Description: PGP signature
