linuxaudio.org

The 44100 Hz sample rate is absolutely the only one ever used for CD's,

but high end audio cards like the Hammerfall tend to be more flexible.

So probably a bug or misconfiguration of the audio card or driver is

causing the wavs to be recorded (and played back) at a faster sample

rate. "arecord" thinks it is getting 44100 Hz data, so that's what it

puts in the header, but it is evidently mistaken. "cdrecord" only knows

what is in the header, so it doesn't realize the data is at the wrong

sample rate. Look for a way to tell the Hammerfall what sample rate to

use, either a module option, ALSA config file option, or a

Hammerfall-specific utility program. Sorry to be so vague, but I've

reached (if not passed) the limit of my knowledge.
On Tuesday 03 December 2002 03:17 pm, patrick reardon wrote:

quoted text
> hello everyone,

>

> i don't know if this is the right forum for my question, but here

> goes.

>

> i'm running on Intel PIII with kernel 2.4.18, ALSA, and a Hammerfall

> 9632 card.  CD quality WAV files recorded with ALSA from live

> performances play back with no problem via "aplay".

>

> a Yamaha CRW8424S scsi burner was recently installed and i burned the

> WAV files to CD with both "cdrecord" and "cdrdao".  data is actually

> transferred but when i play the CD's with a CD player, the tunes are

> too slow and too low by about a minor third.

>

> i tried burning at various speeds from 1x to 8x, but always the same

> problem.  have also tried a variety of other options to "cdrecord,"

> like using a really big buffer, etc.  the commands "file" and "aplay"

> give the following information:

>

> --------snip-----------

> $ file blues1.wav

> blues1.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16

> bit, stereo 44100 Hz

>

> $ aplay blues1.wav

> Playing WAVE 'blues1.wav' : Signed 16 bit Little Endian, Rate 44100

> Hz, Stereo --------snip-----------

>

> i wrote to Jorg Schilling who developed "cdrecord", but he only said

> i need to use 44100 Hz data and that if ALSA wrote incorrect headers,

> i should write the ALSA group instead. i doubt it's a problem with

> ALSA.

>

> at any rate, i'm out of ideas.  has anyone experienced a similar

> problem?  any pointers would be greatly appreciated.

>

> tia,

> patrick

--

"Can you remember the future? Forget it!"