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
