Thanks for your input.
If you think about it, 4.0 milliseconds amounts to 3.2 million clock cycles (at 800 MHz), which amounts to somewhere in the neighborhood of (conservatively) 1 million processor instructions. And compared to the FSB bandwidth, that's one three millionth of what's available. Further, the total data stream of the FP10 (10 input ports at 96000 24-bit samples per second) is 23 megabits per second. That's about one fifth of what the PCI bus can do, about 1/4 of what a firewire interface can manage, and about one two-thousandth of the memory move rate of the computer (DDR2-800). (http://en.wikipedia.org/wiki/List_of_device_bit_rates provides a handy chart for this sort of thing.)
Given the fact that my machine has four independent cores and is running ONLY a single user and a fairly light mix at that, I just have a hard time imagining that I would ever see an XRun at all. There is just too much muscle in a modern computer for that - even in a single core machine.
Your thought about NMIs sounds more plausible. I have suspected that there may be a problem related to the video interrupts. Still, this is a whole lot of hardware to not be able to handle this task fluidly.
I've filed a ticket on the development site. I hope I can get some help with this. I would really like to just RECORD.
On Apr 21 Christopher Shubert wrote:128 frames per period times 3 periods per buffer divided by 96000 samples
> + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3
per second give merely 4.0 milliseconds coverage by buffers. Try a larger
number of frames per period (or, if acceptable, a lower sample rate).
You don't need lots and lots of bandwidth, you need
> Given my hardware, I wouldn't expect to see any XRuns at all.
- guaranteed minimum bandwidth,
- guaranteed maximum latency.
A commodity server/ desktop OS running on commodity PC hardware with a
commodity PC BIOS doesn't give you any such guarantees.
Check the BIOS settings hat anything that might involve NMIs (non-maskable
interrupts, e.g health monitoring) is switched off.
You are using kernel 2.6.35 which should be quite good; nevertheless,
check if there is a newer kernel package available for your distribution.
You could switch to the "performance" CPU frequency scaling governor,
though I don't think the on-demand governor which you are perhaps
currently using increases latency that much.
(Maybe others can comment in detail on your ffado-diag and jack outputs;
I am just an occasional FFADO user.)
-=====-==-== -=-- =-==-