Subject: Re: [ecasound] Moving from v1.9dev5 to v2.0.1 -> performance goes down
From: Kai Vehmanen (k@eca.cx)
Date: Sat Jul 28 2001 - 02:52:03 EEST
On 27 Jul 2001, Teppo Peltonen wrote:
> ecasound -r -z:db -b:128 -i:/dev/dsp -o:/dev/dsp
[...]
> If I want add some effects I have to use -b:256, but that's rather
> tolerable...
[...]
> However, when I upgrade my ecasound to the latest version, 2.0.1, the
> performance unexpectably goes down and I have to use a larger buffer
> size (maybe 1024, can't quite remember)... which is really
> unfortunate.
I'd bet my money on -z:intbuf/-z:nointbuf. In 1.9dev6, -z:nointbuf was
made the default (was -z:intbuf before).
One thing to note is that "-b:128 -z:intbuf" might actually result in
longer latency times than "-b:1024 -z:nointbuf".
The "-b:zzz" option lets you specify how much data the ecasound engine
processes at a time. This doesn't however (directly) affect soundcard
buffering. With -z:intbuf (the old default), soundcard drivers could take
advantage of additional hw buffering.
With -z:nointbuf, the soundcard buffering is limited to 3 fragments
(-b:xxx -> 3*xxx). This magic value of three fragments is the result of
lenghty discussions on alsa-devel and linux-audio-dev. ;) It's considered
to be the optimum setup for low-latency work.
And to add to the mix, independently of -z:intbuf/-z:nointbuf, ecasound
engine always uses the same algorithm to start processing: 1) prefill
soundcard buffers with two fragments (if possible), 2) trigger all devices
at the same time. This is done because ecasound needs direct control of
the soundcard hw (ie. to set the exact time when playback/capture is
started).
So there are quite a few variables. The most difficult part in tuning
these is that different use-cases have different needs. For instance:
1) ecasound -i /dev/dsp -o file.wav
- case: "mp3 player / multitrack mixdown"
- bounded by the soundcard (ie. we can write to 'file.wav'
much faster than /dev/dsp produces data)
- latency is not important
- '-b:1024 -z:intbuf' is a good combo
2) ecasound -i file.wav -o /dev/dsp
- case: "audio file recorder" case
- this is also /dev/dsp bounded
- latency is not important
- '-b:1024 -z:intbuf'; with a 64kB hw buffer and
cd-quality audio, the ecasound->speakers latency can be
up to 370ms (2^16/4096/44100*1000)
3) ecasound -i file.wav -o /dev/dsp -ea:100 -km:1,0,100,74,0
- case: "live interactive control / game sound engine"
- like (2), but now latency is critical (time between turning
a MIDI-knob and hearing the result)
- '-b:128 -z:nointbuf'; expected latency ~6ms (2*128/44100*1000)
- '-b:1024 -z:nointbuf'; expected latency ~45ms (2*1024/44100*1000)
- note! MIDI-latency is not taken into account
4) ecasound -i /dev/dsp -o /dev/dsp
- case: "realtime audio processing"
- both devices run at the same speed
- latency is critical (ie. you are using ecasound as a realtime
fx-processor a'la ecamegapedal)
- '-b:128 -z:nointbuf'; expected latency ~6ms ((1+1)*128/44100*1000)
- as both devices run at the same speed, increasing the
fragment size (-b:x) will have greater impact to reliability
than using '-z:intbuf'
5) ecasound -a:monitor -i file.wav -o /dev/dsp \
-a:record -i /dev/dsp -o file2.wav
- case: "multitrack recording"
- like (5), but slightly more difficult
... now setting the default values is very difficult. For instance, with a
standard, unpatched kernel it's very easy to get scheduling latency spikes
well over 10ms (even 50-200ms spikes are not unheard of). If you don't
run with -r (and the necessary root priviledges), other processes might
also keep the processor which results in even longer timeouts. Without
extensive use of soundcard hw buffering, you'll easily get droppouts. On
the other hand, by using large hw buffers you get long audio delays. This
is why choosing between -z:intbuf/-z:nointbuf is so difficult. It's always
a compromise.
And then there's the whole separate issue of disk i/o latencies (disk
tuning, selecting between -z:db/-z:nodb) ...
Now possible approaches to this problem are:
1) add more configurable buffering parametres
2) make the current configuration options easier
to use (I've got some complaints about of
the current -r/-b/-z:xxx/-z:noxxx mix)
3) add use-case specific options (ie. different
-b, -z, -r, etc options for different types of use)
4) the hardcore approach; require that people apply
lowlatency patches to their kernels, always run with
elevated priviledges (-r), default to -z:db, etc
Good ideas are welcome. It goes without saying that these issues are quite
difficult. In the optimal case, users shouldn't need to worry about any of
these parameters. Ecasound should work reasonably well "out-of-the-box".
> The other problem that I've been having with the newer 2.0.x versions
> is that my ewf-loop files stop functioning properly. I think, that for
> some reason the loop length is computed in a different way and after
> looping for a while the loop gets totally out of sync with the other
Hmm, this needs to be investigated. Can you send me an example .ewf file?
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Jul 28 2001 - 02:51:56 EEST