With this card you can acquire reasonably fast, and generate signals reasonably fast, but you can't do those tasks point-by-point, which is really what you need for your application. Typically, to continuously acquire data into the computer, you set up an acquisition that is hardware timed. That is, the clock on the card times the samples and puts them into a common buffer that is accessible to the computer. From the computer, you pull data out of that buffer to display or save. It is not efficient at all to try to get each sample as it appears in the buffer; the way to do it is to take all of the samples out of the buffer at a reasonable time interval (I usually use 0.1 second). So, for an acquisition rate of 100k, you are pulling 10k samples from the buffer 10 times a second. A PC running windows is not "real-time". What this means is that there is no guarantee that any particular task will occur in a defined period of time. Sometimes it will take Windows longer than 0.1 seconds to get the data because there are other tasks going on that take precedence over what you are asking the computer to do. In my example of 100k S/sec with reads occuring every 0.1 second, I would configure the buffer to be about 100k samples in size. That means I've got up to a second to get samples out of the buffer before the buffer is overrun, and an error is produced.
Analog outputs work the same way. You set up the generation to be hardware timed, and you define a buffer where you start drop in samples. The acquisition card pulls data from the buffer as it needs it, and you just need to make sure you are putting data into the buffer faster than it is taking it out. Again, you can't do this efficiently one point at a time.
For your application, you want to minimize the lag between when sampels are read from the acquisition buffer, and samples are put into the analog output buffer. Ideally, each point would be read and transferred to the output buffer immediately. You can do this on an FPGA (easily at 100kS/sec rates) or on a real-time PC (probably at 10's of k S/sec, maybe 100k), but on a non-real-time PC, you are pushing it trying to route 1k S/sec this way. Maybe it's a little better than that, but it will not be real-time (i.e., deterministic), so if someone wiggles the mouse, your samples rates will be fried. This is so slow because the data has to come in through the acquisition card, be transferred to the PC, wait on your software timed code to put back down to the acquistion card, and then activate the generation. On the FPGA, this can all be routed within the hardware, so you are dealing with hardware timing the whole way.
It's at little confusing, but if you experiment with it, you will see what I mean. Take a look at how quickly you can generate a signal when you only provide one point at a time, as opposed to streaming with a buffer.
Chris
