If you're calling DAQmx Read inside a while loop and wondering why you can't sustain more than a few kS/s, the problem is almost never your hardware.

It's your buffer configuration.

The Default Trap

When you create a DAQmx task with default settings, NI allocates a buffer based on your sample rate and a conservative multiplier. For most use cases, this is fine. But if you're doing high-speed continuous acquisition — say 500 kS/s or above — the default buffer becomes a bottleneck.

Here's what happens:

• You call DAQmx Read requesting N samples

• The driver checks the buffer, sees fewer than N samples available

• Your thread blocks, waiting for hardware to fill the buffer

• Meanwhile, your UI thread freezes and your timing measurements show jitter

The fix is straightforward: configure your buffer explicitly using DAQmx Configure Input Buffer, and set it to at least 10× your read size.

The Bigger Problem: Software Timing

Even with a properly sized buffer, if you're using software-timed reads (no hardware clock), your sample rate is at the mercy of Windows scheduling. A GC pause, a background Windows update check, or even a screen redraw can introduce milliseconds of jitter.

The solution is hardware-timed acquisition:

1. Set your sample clock source to the onboard clock (or an external reference)

2. Use finite or continuous sample mode — never on-demand for high-speed work

3. Let the hardware handle timing; your software just reads from the buffer

This alone typically improves throughput by 5-10× and eliminates timing jitter entirely.

One More Thing

If you're synchronizing multiple devices, don't assume starting two tasks "at the same time" is good enough. Even a 1 ms offset at 1 MS/s means 1,000 misaligned samples. You need shared clocks and start triggers via RTSI or PXI trigger lines.

I cover all of this — buffer management, hardware clocking, multi-device sync, and RT deployment — in the DAQ Mastery Course inside Nim Performance Lab.