Thanks Brad,
Your feedback was helpful in changing our direction and going a different route for a comprimise intermeadiate solution (saved me from further banging my head against the hardware timed acquisition). Low overhead unbuffered acquisition is still a needed feature for us, so I am curious what the trajectory is like for bug fixes (resolution of corrective actions). Would the fix show up in the next NI-DAQ driver?
As for the real-time requirements and Windows, while it's true that for real-time applications violation of a single timing constraint can be catastrophic, for a good deal of applications it's a matter of statistical coherence that depends on the application. If the program works under windows with real-time behavior 95% of the time, that may for example result in 80% good data or operational utility without catastrophic consequences. A good deal of our applications with real-time requirements fall into this category and functions that allow achieve real-time behaviour, at least part of the time, are still very usable.
