4 Sep
2009
4 Sep
'09
10:45 p.m.
On Fri, Sep 4, 2009 at 7:58 PM, Louis
Gorenfeld<louis.gorenfeld(a)gmail.com> wrote:
Hi,
I have a program which, at 2-periods per buffer with 128 samples per
period size and 48khz sampling rate, takes 9ms to pass input through
to its outputs. However, with the same hardware and settings, I
notice that JACK+Ardour2 take only 6ms (this is through the program,
not through a direct monitoring mode-- effects can be applied to the
input). The amount of extra latency I see in my program increases
with the buffer size: it is one buffer extra in our program. I have
a few questions about this on which I haven't been able to find
sufficient material with Google.
One difference between JACK and our software I notice is that JACK
is using ALSA's mmap mode. I am unclear on the advantages of mmap's
begin/commit access vs. using the plain vanilla readi/writei. If mmap
does offer a latency advantage and not just a CPU advantage, how does
the timing of that work as compared to read/write? Where's my extra
buffer worth of latency coming from?
when the audio interface interrupts the cpu, the OS wakes up JACK.
JACK runs the ALSA backend to read incoming audio, then wakes any
clients, then runs the ALSA backend to write outgoing audio. this all
needs to happen before the next interrupt arrives.
the ALSA backend uses mmap to write data directly into the h/w buffer
used by the audio interface (to the extent that the h/w makes it
possible to do so). this means that if you are using 2 periods per h/w
buffer, at the time of the *next* interrupt, the data will already be
in the h/w buffer ready to be played out (assuming that everything
went according to plan).
if you use read/write, you deliver/receive the data to/from the kernel
at the time of calling. but there is then an extra buffer inside the
ALSA midlevel driver code that holds the data till it is needed (in
both directions). the size of this buffer is controllable, and can be
set so that it effectively adds no additional latency, but at that
point it also doesn't serve any purpose than requiring more CPU cycles
to deliver the data (i.e. you set it equal to one period). you might
as well just use mmap at that point BUT only if you are writing data
in a format understood by the h/w. if not you will either have to
accept the extra latency, or tune the kernel buffering size to
minimize it. JACK doesn't use ALSA sample format code at all - we
always write data to the h/w buffer in a format that we know the h/w
understands. i am afraid i do not remember the parameters you need to
play with, but aplay -vv and/or the ALSA docs on "s/w parameter" will
provide a clue.
--p