Re: [ecasound] buffering question

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] buffering question
From: Raoul Bönisch (
Date: Wed Dec 25 2002 - 23:25:50 EET

Hi list!

On Wed, Dec 25, 2002 at 04:24:05PM +0000, The Eye wrote:
> I mainly use ecasound for recording-purposes, e.g. recording really long
> stuff from the radio and so on (using ecasound because of the largefile
> support).

That's great! You can use ecasound for anything.

> Been using some 2.1.something up untill a few days ago .. pulled the new
> CVS, compiled that and use that ..
> so since I saw the -B option in the man-page I tried that out
> (-B:rtlowlatency) for my last recording session .. but right in the
> middle of recording (after like 1.5 hours) I start getting lots of
> drop-outs .. and error messages that say:
> (audioio-alsa) warning! playback overrun - samples lost! Break was at least 0.21 ms long.
> or similar.

That's strange. Perhaps there are other processes started by cron
or something? Or is it a bug?

> So when thinking about this I realised I don't know much about buffering
> and what it all means .. I mean the man-page says I can use
> -B:auto|nonrt|rt|rtlowlatency ... plus there is this -z:db feature and
> the fact that I can use -b:buffer_size ...

I don't know too much about it, too.

> at some stage (with -b I think) there is mention of "for real-time
> processing you should set this as low as possible" ..

Right. A big buffer means many samples can be stored before being
played or recorded. This means a long delay.

> Now I'm wondering .. what _is_ real-time processing as applied to a
> tool like ecasound? and what is it that I am doing (recording long

For example if you connect an electric guitar to your computer and
want to play on it, it is important that the sound is played on
the soundcard right at the time you strike the strings. This is
realtime processing. Little time like about 10 ms does not do any
harm depending on what you want to do. It could sum up to more
time if you do repeatitive multitrack recording!

> stretches of audio, preferably so that any other acitivity on my PC will

Well, it's just sound processing. I don't know any other word for
it. Of course it's a kind of "realtime" as the sound shouldn't
have any clicks and drop outs. But it is not important if the
recorded sound is stored to disk some seconds later than it came
in from the radio. Even a latency of minutes wouldn't be much of
a problem only that you would have to wait these minutes after
stopping recording until the storage on disk is complete.

> have no negative effect on my recording), and what would be good
> settings for that? I even realised that I don't really understand what
> "low latency" actually means.

Latency is for example the time which passes from striking the guitar
string to the sound of the guitar being played on the speakers. It
is caused by the processing of the computer and sound hardware. For
your purposes a big buffer would be best. As I wrote latency of a
few seconds does not matter for recording radio sound and if you
run other processes on your machine a big buffer can avoid drop outs!

> So if anyone can shed some light on this or point me in the direction of
> some howto/faq/explaining documents, I'd be real happy.

Sorry, I don't know any such pointers. But you should get many
hits on google.

> Hardware is (dunno if this is important):
> Athlon XP 1700+
> 512 MB DDR-RAM
> TerraTec EWX 24/96 soundcard, using alsa-0.9.0_rc2

The hardware is important if it comes to realtime processing as
it has to be fast enough. The faster, the more processing can be
done in realtime. E.g. you can add more effects to the sound.

But you don't need to do realtime processing for you radio


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 25 2002 - 23:21:23 EET