>> <nitpick>
>> Now what is our definition of latency, exactly? 256 byte periods =
>> 1.45ms between interrupts, according to simple calculations - so we're not
>> at the sub-1ms level yet, at least :)=
>> </nitpick>
>
>Right.. I've used the word really confusing.
>The latency is of course 2 (up to 3) msec.
i've harped on about this before. there are 2 kinds of latency:
1) input or "event" latency - how soon after something happens
(e.g. an audio sample has value N) can you know about it?
2) output or "through" latency - how long after receiving
data can it be re-emitted?
type 1 is solely determined by the frequency at which you inspect the
data stream. unless you use mmap mode+RTC+hw-pointer, this is
determined by the period size (i.e. the audio interface interrupt frequency)
type 2 is mostly determined by the overall buffer size, unless you
allow buffer overwriting (Jaroslav indicated that he was going to
allow this to help game writers). if you do allow overwriting, then
type 2 is limited by the transfer size between the h/w and the CPU.
its helpful to distinguish between the two of these.
there is also "kernel scheduling latency", which is what Andrew's tool
measures, and is defined by the ability of the kernel to meet
scheduling deadlines. its a determining factor in whether or not an
application with RT-like requirements can run successfully or not.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
