Subject: Re: [ecasound] weird delay in real time processing
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Sun Jun 11 2000 - 20:01:50 EEST
On Sun, 11 Jun 2000, S. Massy wrote:
> - Whenever I'm doing some realtime playback/recording with something
> # ecasound -i:/dev/dsp -o:/dev/dsp -r
> I still get the variable lag (from none to about one second) between
> ins and outs. The only clue I might have found so far is that the
> problem seems less important when not using double buffering.
Hmm, double buffering only affects file objects. The above example
should work fine, even without -r.
> On a side note here's an excerpt from the Low-latency howto:
> "If you plan to stream audio from/to disk, use a 2 threaded model:
> Am I wrong to think that when running with -m:mthreaded and -r options
> all threads are actually SCHED_FIFO? If so, would the idea of
> implementing the suggestion above be worthwhile, something like a -rt
Well, I'm a long time member of LAD (linux-audio-dev) and I know the
people who wrote those how-to documents. :) SCHED_FIFO in general
continues to be one of the most popular subjects. The 2-thread model is a
good one, but it's clearly aimed at certain use cases. Unlike many other
apps, ecasound isn't specifically geared toward specific uses. In the
2-thread model, you have to separate sound card devices and file
operations. Ecasound however doesn't make any difference between various
types of audio objects. This is flexible, but makes things a bit more
complex to implement.
Anyway, in normal case, you shouldn't need to use -r or -m options. If
ecasound doesn't work with simple "ecasound -i /dev/dsp -o /dev/dsp", then
it just won't work (= problem is elsewhere). I admit that there are lots
of areas where ecasound's performance could be tuned, but I also try to
keep a healthy balance between speed-hacks and high-level design. Once you
have a good design, it's much easier to start tuning for speed.
But, but, I'm very interested in these things and I'm constantly trying
out various threading/mixing schemes, so things are improving all the
And back to your problem, while writing this message I've been sampling my
drum machine with "ecasound -i /dev/dsp -o /dev/dsp -c" and so far (about
30 minutes of sampling) no problems. I'm using SB128PCI with ALSA 0.6.x's
OSS emulation and the latest ecasound CVS version. What signals are you
monitorin (both the incoming and outgoing, or just outgoing)?
How about the rest of you on this list? Are you experiencing similar
problems? It's very really difficult for me to fix a bug if I can't
reproduce it... :(
-- Kai Vehmanen <email@example.com> ---------------- CS, University of Turku . . audio software for linux .. http://www.eca.cx . . armchair-tunes mp3/wav/ra . http://www.wakkanet.fi/sculpscape .
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Tue Jun 20 2000 - 07:46:23 EEST