Re: [ecasound] New double-buffering: report after a quick try

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] New double-buffering: report after a quick try
From: Kai Vehmanen (
Date: Tue Nov 21 2000 - 18:23:23 EET

On Mon, 20 Nov 2000, S. Massy wrote:

> that every time ecasound would exit (after underruns or with the quit
> command) all output was frozen: that is although I could type commands
> they would no longer be displayed, and I had to exit and relogin each

'reset' command (from the ncurses package) is your friend here.

> Over all it acted in a rather unstable manner, sometimes stopping in
> the middle of playback for apparently no reason: looking to the file
> position (with the fs command) showed me that ecasound really thought
> that it was arrived at the end of the file. I did all my testing using

Hmm, yes, at the moment end-of-file occurs about 1-2secs too early because
of the buffering. This will be fixed.

> a 16 bits stereo wave file, playing mainly with the buffersize
> (-b). /dev/dsp was very severely affected and, while it was stable
> enough to give some playback with a buffersize of 1024, it was
> basically impossible to get anything to play for more than 2 seconds
> once I had lowered the buffersize to 256. Things were much better with

True. At the moment, size of the double-buffer is hard-coded to 64 *
buffersize. So if you lower the buffersize much beyond 1024 (which I
used for testing), -z:db won't work. When the overall size of the db-area
falls below soundcard's buffersize, underruns will rigth after start
(writing directly to soundcard's memory buffer is way faster than
writing to disk). For -z:db to work properly, this should be just the
other way around. Normally when soundcard's buffers are full, writes to
soudncard block for a long time (=realtime speed).

> /dev/dsp), even with low buffersize. Oh, one more thing, commands to
> move around in the files, such as fw, rw and setpos, yielded VERY
> strange results, not the ones expected at any rate.

Ah, they should work, but when you set a new position, the db-buffer area
isn't (yet) flushed. So you'll first hear few seconds from the old
position, and then playback will move to the new position. This will have
to be fixed.

> - My kernel version is 2.2.17 (If I remember well I have not applied the
> low latency patches this time)
> - There are two IDE drives in there (which I tuned with hdparm)
> - My CPU is a Pentium II (266MHz)
> - And my sound hardware is managed by ALSA 0.5.9D

Ok, thank you! This was very helpful. I'm testing with a completely
different environemnt: 2.4.0-test11, tuned IDE-drive, SMP-celeron and
the 0.6.x ALSA drivers. I suspect the SMP<->UNI difference is the most

I'll let you know when I get these fixes ready.

 . ... [ audio software for linux ] /\ . 
 . [ my armchair-tunes mp3/ra/wav ]

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 17:54:56 EET