On Thu, 8 Apr 2004 18:14:02 -0400 stan <stanb@panix.com> wrote: >On Wed, Apr 07, 2004 at 02:48:59PM -0400, Chris Metzler wrote: >>On Wed, 7 Apr 2004 12:04:43 -0400 >>stan <stanb@panix.com> wrote: >>>On Tue, Apr 06, 2004 at 11:38:16PM -0400, Chris Metzler wrote: >>>>On Tue, 6 Apr 2004 15:43:30 -0400 >>>>stan <stanb@panix.com> 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 cmetzler@speakeasy.snip-me.net (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
Attachment:
pgp7rf5xWoFr_.pgp
Description: PGP signature