Subject: Re: [linux-audio-dev] stats please.
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Oct 12 2001 - 20:13:17 EEST
>> Someone had a good idea on alsa-devel to make an advertisement for the
>> lowest latency achieved on a linux system. It makes sense so I'm going
>> to add something to the LAU guide webring.
>>
>> I would like to know two things.
>>
>> 1: What is the lowest latency achieved so far and on what hardware.
>
>let's not hype.
>the trick with latency is not which all-time record you get *once*,
>but how big a latency you will get in *worst case*, so that you can
>rely on it without being hosed when a deadline is missed.
Absolutely. But its much more complex than that:
Andrew's own tests suggest that on a modern CPU, his patches provide
about 99.5% probability of satsifying 0.75msec scheduling deadlines.
However, this doesn't mean Linux can support 0.75msec audio
latency. For a start, audio latency means round-trip times for audio
(the time between a signal (analog or digital) being received at an
input connector of the interface, and the "matching" signal being delivered
to an output connector.
This means in turn that the figure is going to be bounded by the
interval used to retrieve data from the h/w, which in turn is governed
by a combination of h/w design (maximum interrupt frequency and
reliability of the hardware pointer) and/or application design
(whether the hw pointer is used directly, or the interrupt is used to
signal "data/space ready"). Assume for a moment that the device
interrupt is used. Most modern cards limit the interrupt frequency to
about 64 frames (if you know of any that go lower, please let me
know). At 48kHz, thats about 1.3msec per interrupt. With a minimum of
2 "periods" per h/w buffer, thats 2.6msec of roundtrip time, enforced
by the h/w design (without s/w hacks to get around them).
Linux+lowish can generally meet such deadlines with at least 99.9%
probability as long as the correct disk drivers are in use and
Andrew's list of "don't do this" is obeyed. You can cause the deadline
to be missed by applying extreme VM pressure.
Beyond that, there's not much point in claiming lower latencies, even
though they could be theoretically obtained, because to do so requires
application design that is non-portable and kludgy at best. I don't
know of any applications that use the approach that would be required
to get lower results.
I would therefore simply note, as I have done in the past, that Linux'
audio latency is limited *only* by *audio* hardware design, and leave it
at that.
--p
This archive was generated by hypermail 2b28 : Fri Oct 12 2001 - 20:10:36 EEST