7 Oct
2003
7 Oct
'03
12:25 p.m.
On Mon, 6 Oct 2003, Ivica Bukvic wrote:
Admittedly, it's quite old but that, if anything
speaks only in Linux's
favor in terms of its pro-audio readiness. At any rate, I was checking
out the benchmark data and was wondering as to how did this
person/software app get to the 0.73ms buffer fragment that is equal to
128bytes? In other words, what sampling rate was used?
128 bytes / (44.1 samples/ms * 4 bytes/sample) = 0.7256 ms
16 bit stereo sample = 4 bytes/sample
he was using 3 fragments of 128 bytes, which was giving him a buffer of up
to 2.1 ms latency.
these results are just with his latencytest program, though. you need to
test whatever program you are using to find it's actual results.
with pd, if i set the number of frags to 1 and the fragsize to 128 at a
rate of 48000 it tells me the audiobuffer is 0 ms, 2 or 3 frags is 1 ms,
and 4 frags is 2 ms (i think it's dropping the remainder). using
latency.pd with these settings gives me 4 ms for 1,2, and 3 frags, and
5.33 ms for 4 frags (with an uncertainty of 1.45 ms). considering this,
latency with pd for me is about 2.5 ms, even when stessing the cpu.
another way to test latency is to feed a live sound through a program on
one channel and then feed it's output, along with another channel of the
same sound not going through the program, to another soundcard, recording
this and seeing the time difference in channels using a sound file editor.
you can actually see and hear the latency this way, and not just go off
some program that gives you ideal or approximate results.
-dave