On Fri, Sep 4, 2009 at 7:58 PM, Louis Gorenfeld<[email protected]> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
