Subject: Re: [linux-audio-user] full duplex latency on ac97 / kernel woes
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Tue Jan 22 2002 - 01:32:01 EET
On Mon, 21 Jan 2002, Swirl Ly wrote:
> ecasound same thing, i get underruns.
[...]
> i posted earlier, no response? could this be a hardware issue with the
> ac97? because my kernel latencies seem to be OK, yet im still getting
> underruns in ecasound and jackd.
You could try installing a devel version of ecasound (2.1dev7 is the
latest) and run some tests with it. The devel versions always output some
latency statistics to stderr after processing ends. These can be useful
when tracking performance problems.
For instance with "ecasound -i big_10ch_file.wav -o alsa,default -b:128",
I get the following:
--cut--
(eca-engine) *** profile begin ***
Loops faster than realtime: 3097 (<2.9 msec)
Loops slower than realtime: 349 (>=2.9 msec)
Loops slower than realtime: 2 (>5.8 msec)
Loops exceeding all buffering: 0 (>185.8 msec)
Total loops: 3446
Fastest/slowest/average loop time: 0.4/18.2/2.8 msec.
(eca-engine) *** profile end ***
(audioio-proxy-server) *** profile begin ***
Profile_full_rep: 1
Profile_no_processing_rep: 36
Profile_not_full_anymore_rep: 4003
Profile_processing_rep: 152
Profile_read_xrun_danger_rep: 2704
Profile_write_xrun_danger_rep: 0
Profile_rounds_total_rep: 4192
Fastest/slowest/average loop time: 0.0/4.1/0.3 msec.
(audioio-proxy-server) *** profile end ***
--cut--
The first set of values represents the engine loop (task scheduling),
while the second the disk i/o thread (disk i/o latency). Especially useful
values are the slowest and average loop times, and also the "loops slower
than realtime" and "loops exceeding all buffering" fields.
Note that when rt-operation is one-direction only (only
playback/recording), ecasound automatically increases soundcard buffering
(note the 185.8msec -> 64 * 128 bytes of soundcard buffering). If you
replace big_10ch_file.wav with an ALSA input (and ecasound is run with
root priviledges), you'll note that buffering is reduced to 3 * 128 bytes
(~8.7msec). You can override this with -z:nointbuf option. If you don't
explicitly give an -b option, the default sizes are 8*1024 bytes and
3*1024 bytes.
Trying with different setups (just full-duplex recording and playback
without files, typical full-duplxex recording setup with monitor tracks,
etc) can help to locate the source of problems.
Btw; The above statistics are not very good. I run the above
test with a standard kernel without root priviledges. The slowest
engine loop was 18.2msec, during which more than six 128-byte
audio buffers were played back by the soundcard hardware.
This time I didn't get an xrun as ecasound had configured
the soundcard to use 64 128-bytes buffers (-> 185.8msec).
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Tue Jan 22 2002 - 01:23:43 EET