Subject: Re: [linux-audio-dev] absolute minimum latency (was Re: ADAT clicks)
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Apr 06 2000 - 20:35:20 EEST
Sorry Paul, you are totally wrong here:
why the h** should we do a memcpy() of 4MB of
data for each 3ms latency cycle ???
(what would be 300 (1/3ms) memcpy()s per sec = 1.2GB/sec !!
now let's explain:
If we run with let's say 2ms buffersizes ( with double buffering we have 4ms
latency), we have to memcpy() 2ms worth of data for EACH cycle:
4608000 bytes/sec * 0.002 sec = 9216 BYTES PER EACH CYCLE
now if we do worst case assumption: 20msec to copy 4608000 bytes
then copying 9216 bytes takes:
20msecs * 9216/4608000 = 0.04 msecs = 40usecs !!
compared to the 2msec cycle duration the 40 usecs is 2% of 2msecs
that means in the worst case you burn 2% of the CPU (notice that your
timing includes scheduler jitters too , therefore your estimates are way too
pessimistic) to copy the data around.
plenty of % CPU left to do useful work.
My 60 track harddisk playback code reads data at a rate of 5-6MB/sec
while the audio loop runs with a 3ms latency buffer size.
with the low-latency patches it works like a charm, using about 15% of CPU,
but that % CPU is burnt by the harddisk EIDE driver.
So yes, it is possible to achieve 2-3ms easily.
hope this helps,
Benno.
On Thu, 06 Apr 2000, Paul Barton-Davis wrote:
> >This makes no difference except that you can cut latency from some
> >3-5 ms down to around one sample + whatever delay there is in the
> >converters and analog cirquitry.
> >
> >Oh, AFAIK, ProTools has more than 3 ms latency anyway, BTW. I don't
>
> Warning: 24 channels of audio 32 bit audio data at 48kHz = 4.39MB/sec
>
> I ran the following test program on my machine:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <asm/msr.h>
> #include <sys/mman.h>
> #include <sched.h>
>
> #define BUFSIZE 4608000
> #define CYCLES_PER_USEC 450.0f
>
> main ()
>
> {
> char *abuf;
> char *bbuf;
> unsigned long now, then;
> int n;
> unsigned long min = 999999;
> unsigned long max = 0;
>
> unsigned long diff;
> struct sched_param sp;
>
> abuf = (char *) malloc (BUFSIZE);
> bbuf = (char *) malloc (BUFSIZE);
>
> memset (&sp, 0, sizeof sp);
> sp.sched_priority = 10;
>
> if (sched_setscheduler (0, SCHED_FIFO, &sp) != 0) {
> fprintf (stderr, "can't become realtime thread\n");
> return 1;
> }
>
> if (mlockall (MCL_CURRENT | MCL_FUTURE) != 0) {
> fprintf (stderr, "can't lock down pages\n");
> return 1;
> }
>
> for (n = 0; n < 1000; n++) {
> rdtscl (then);
> memcpy (abuf, bbuf, BUFSIZE);
> rdtscl (now);
>
> diff = now - then;
> if (diff < min) {
> min = diff;
> }
> if (diff > max) {
> max = diff;
> }
> }
>
> printf ("Minimum usecs for 1 copy: %.2f\n",
> (float) min / CYCLES_PER_USEC);
> printf ("Maximum usecs for 1 copy: %.2f\n",
> (float) max / CYCLES_PER_USEC);
> }
>
> On my machine it prints:
>
> Minimum usecs for 1 copy: 2222.22
> Maximum usecs for 1 copy: 42504.73
>
> The minimum value never varies, the maximum value has about +/-
> 500usecs of variation.
>
> To put this in slightly starker terms: just *copying* the data from
> the buffer used by the audio h/w to some other piece of RAM takes
> 2.2msec. You can forget *ever* getting lower latency than this, since
> this figure (or its value on your machine) is the *absolute* minimum
> time it will take to do absolutely zero processing on the audio data
> (it has to be copied at least once before it can be written to disk,
> to avoid dropouts caused by disk i/o; likewise for the simple "direct
> through via software" case, where the copy is simply back to the
> playback buffer used by the audio h/w).
>
> This includes no surrounding code, no logic, no cache misses, no
> nothing. Worse, it doesn't take into account that the copy doesn't
> happen as one single chunk of 4.39MB, but as 24 copies of 192000
> bytes. How do the numbers look for this case ?
>
> Minimum usecs for 1 copy: 813.12
> Maximum usecs for 1 copy: 1042.6
>
> Thats about 20msec (24 * 0.813) absolute minimum latency for 24
> channels.
>
> So, talking about latencies of 3msec for this kind of application is
> shouting into the wind without significantly faster low level system
> throughput.
>
> >instead, if you use the digital I/O. Involving a digital console very
> >likely adds some more latency.
>
> Mackie claims 1.3ms. I don't know if I believe them.
>
> --p
-- Benno Senoner E-Mail: sbenno_AT_gardena.net Linux low-latency audio / scheduling latency benchmarks http://www.gardena.net/benno/linux/audio
This archive was generated by hypermail 2b28 : Thu Apr 06 2000 - 23:05:05 EEST