Subject: Re: [ecasound] Problems with recording
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Tue Mar 20 2001 - 10:54:18 EET
On Mon, 19 Mar 2001, Remco Poelstra wrote:
> I recorded a song from my md to my computer.
> I used ecasound -r -i /dev/dsp -o file.wav
> My system was doing nothing and my harddrive could handle it with ease.
> Still there are glitches in the recording. How is this possible?
> I've a SB Live! with Asus A7V motherboard and Maxtor harddrive.
Unfortunately this is possible. For instance if your drive is not properly
tuned, or you have a bad kernel version for streaming (some 2.4.0test
kernels were pretty bad), some write() operations might take so long that
/dev/dsp buffer overflows... This is a kernel-level problem (disk i/o
latency), so even raising the priority -r won't help. This is precisely
the reason why I've wasted so much time into the new disk streaming
subsystem. I recommend you to try it:
ecasound -r -i /dev/dsp -o file.wav -z:db
> Is this perhaps more an alsa problem, or badly behaving hardware. I really
> can't believe it's a problem in ecasound, because it has time enough to
> record it.
This is always a possibility. Although 0.9.x ALSA is getting more stable
all the time, it's still beta and contains lots of recently modified code.
As the OSS API has no mechanism for reporting buffer xruns, you should use
the ALSA native interface and add -z:xruns to the cmd-line (requires
ecasound 1.9dev2 or newer). So if you are using the new ALSA 0.9.x ...
ecasound -r -i alsahw,0,0 -o file.wav -z:db -z:xruns
This way the recording will stop if xruns occur... If you still get
glitches (no xruns reported), then it's probably a hw-related problem.
... with older ALSA releases, replace "alsahw,0,0" with "alsa,0,0".
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Tue Mar 20 2001 - 10:58:57 EET