Subject: Re: [ecasound] Re: [Jackit-devel] writable port and client names
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Sat Dec 22 2001 - 23:10:42 EET
This still comes to both lists, but followups should go only to
On Sat, 22 Dec 2001, Jeremy Hall wrote:
>> Yes. This requires that you run ecasound with double-buffering enabled
>> (v2.0: -z:db, v2.1->: automatically detected). When enabled, all non-rt
> every time I envoke ecasound, I always have to add -z:nodb -z:intbuf -r to
> my cmdline, otherwise I get hoards of lag. Some operations seem to cause
> a jump in audio, like removing effects.
-z:nodb/-z:db will cause a huge delay to processing disk and other
non-realtime i/o. In normal uses this is a non-issue. Of course if you are
have a non-realtime audio object piping data to for instance a network
client, then you will notice the delay which can be measured in
_seconds_ (yes, you just _have_ to have large buffers when dealing with
As for -z:intbuf/-z:nointbuf, it controls how much soundcard buffering
should be used. With -z:nointbuf, this is 3 periods/fragments, with
-z:intbuf, a considerably larger value. So when latency is an issue, you
absolutely _must_ use -z:nointbuf! Btw; ardour&jack defaults to 2 periods.
I remember that 2 periods works very nicely on Hammerfall, but for other
cards I think 3 is better (this has been discussed many times on
alsa-devel and lad).
Then the third relevant option is the period size. Jackd/ardour defaults
to 64 frames. In ecasound you would specify -b:64 (default is -b:1024).
Ecasound's -r option is equivalent to jackd's -R.
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Dec 22 2001 - 23:02:43 EET