The interrupt latency argument is very believable, though since I'm able to get 9kfps right now I'd say my latency has to be at least as low as ~100 us.
Throughput and latency are very different. For instance, it could be possible to be processing 9kfps with 10ms of latency from image capture to processing (your buffer list must be long enough though or else you would end up skipping frames from even being acquired). Since the board acquires asynchronously from your processing, both sides can achieve a high throughput even though there could be latency from one to the other.
I agree that the NI-1483R and the associated FPGA modules would likely be the answer here, though not a cheap one. Do you know off the top of your head if they are capable of doing FFTs?
Not sure, but it seems so: http://digital.ni.com/public.nsf/allkb/E8C29E834503EDE2862574DD0071B8A4
1. With regards to buffer protection, I thought the whole point of putting 100 or so buffers in a ring is that you could write to one buffer while reading from another. Is that wrong or are there another set of buffers that effectively impose this restriction regardless of my ring? (This is related to the LL ring buffered acquisition demonstrated in \National Instruments\LabVIEW 2009\examples\IMAQ\IMAQ Low Level.llb )
Yes, this is a correct interpretation. You put 100 buffers in the ring and the hardware fills them in a circular fashion. You can then wait for a particular buffer number to be ready and extract it, preventing it from being overwritten by the hardware. Note that the semantics of buffer extraction vary between IMAQ (framegrabbers) and IMAQdx (bus-based cameras).
2. This may be a case of symantics, but in MAX, it diplays "displayed/acquired" and not "processed/acquired". Yes, the "displayed" number is quite a bit lower (in fact it's much lower than even the rate I'm getting in my VI) and I had assumed that this involved a bottleneck associated with getting the pixels from system memory to the display. Since my framegrabber supposedly has no internal memory (it has a direct pipe to the system RAM via the PCIe bus), the "acquired" number (if it is real) must mean the rate of frames making it to the system memory. Is there some low-level way to access that memory in a round-about way without assigning any protection to the buffer?
Yes, MAX's "displayed" is essentially a Grab Image + Display. Since Grab is essentially Extract-Copy-Release, the whole sequence MAX does is "Extract latest image - Copy - Release - Display Copy". The rate at which this happens is the "displayed" rate. The rate at which the hardware puts the images into memory is the "acquired" rate. The way the IMAQ framegrabbers/drivers work is that the hardware has full write access to the entire circular buffer list unless the software puts a lock ("extract") on a buffer. The acquired rate will always equal the camera's frame rate unless the hardware loops around and hits an extracted buffer and can go no further. As long as you guarantee you keep a buffer extracted for less time than the time it would take to loop around the buffer list, the hardware will not drop frames in this manner (though your extraction/processing of them might not be able to keep up).
As for a low-level way to access the buffers without protection, since the IMAQ Ring VIs simply lets you pass in the buffer list of Vision images when you configure the hardware, you essentially already have access to the buffer list and can access them however you want. Buffer numbers in IMAQ translate to buffer indices as a simple modulus function. Obviously if you use no protection at all you cannot guarantee the results of your processing. However, if you extract one buffer you know that all the buffers newer than it are protected as well and can simply access them directly.
Eric
