Subject: Re: [ecasound] -z:intbuf
From: S. Massy (email@example.com)
Date: Wed May 30 2001 - 03:32:21 EEST
On Wed, 30 May 2001, Kai Vehmanen wrote:
> On Wed, 16 May 2001, S. Massy wrote:
> > Recently I noticed a great decrease in stability when doing simple
> > playback with ecasound, where the smallest thing, and sometimes nothing
> > at all, would trigger xruns. Today I finally understood that it is
> Btw; have you tested with other drivers than ALSA 0.9.x... I'm getting
> quite a lot of xruns with 0.9.x, and I'm not sure who to blame here. It
> might be that ecasound is using the new ALSA API inefficiently, or a bug
> in my soundcard's lowlevel drivers, or... Anyway, a benchmark between
> different drivers (old ALSA, OSS/kernel, OSS/com) wouldn't hurt at this
For me ALSA 0.9.0 is definitely the most reliable: ALSA 0.5.x has always been
rather unstable for me and OSS was a nightmare.
With intbuf on I practically never get xruns, except under great system loads
in which case -z:db is usually the remedy.
If you experience xruns that don't seem to have any cause you definitely
should try intbuf on again.
> > this as it depends on what sort of operation the user performs most
> > often. I therefore suggest to make it a config file option just like
> > -z:db, something like "enable-internal-buffering = true/false" so that
> > people would be free to choose whichever behaviour they prefer.
> True, this should be added. But which setting should be the default, now
> that's a difficult one. With -z:nointbuf, people might experience ecasound
> as unstable, while with -z:intbut, you get weird latency problems...?
Well, for my particular system, intbuf on by default would be the way to go
because I only need nointbuf when doing fully real-time processing, while for
any other form of processing nointbuf is just a plain nightmare. But that's
for MY system...so I guess there's no true answer.
> Audio software for Linux!
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <firstname.lastname@example.org>.
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Wed May 30 2001 - 03:31:27 EEST