I'm using a USB-6216 for a hardware-timed, buffered analog output task, with regeneration off, via DAQmx in C++.
Let's say the task is: I want to generate a sine wave at 1kHz, and a user is going to manually control the frequency of the sine wave. So of course the buffering is going to add some latency, but I want to reel in that latency within reason. And if I can't keep up, I understand I'll get a buffer under-run error.
My sampling rate is 1kHz, and I'm setting my buffer size to 10000 samples (10 seconds). I'm logically creating a "chunk size" of 1000 samples; this is what I'll write out whenever I get my EveryNSamples callback.
So here's how I hoped things would work:
DAQmxCreateTask(...)
DAQmxCreateAOVoltageChan(...)
DAQmxCfgSampClkTiming(taskHandle,"",1000.0,DAQmx_Val_Rising,DAQmx_Val_ContSamps,10000));
DAQmxSetBufOutputBufSize(10000);
DAQmxSetWriteRegenMode(taskHandle, DAQmx_Val_DoNotAllowRegen));
DAQmxRegisterEveryNSamplesEvent(taskHandle,DAQmx_Val_Transferred_From_Buffer,1000,0,EveryNCallback,0));
// Now I need to write out a couple chunks before I start the task, lest I should immediately have an under-run. I'm going to write THREE
// "chunks" (3000 samples) in this example.
for(int i=0; i<3; i++)
{
// Assume I'm filling in sine wave data into "data" at each iteration
DAQmxWriteAnalogF64(taskHandle,1000,0,0.0,DAQmx_Val_GroupByChannel,data,&samplesWritten,0);
}
DAQmxStartTask(streamingTaskHandle));
Now in my "EveryNCallback", I'm going to generate the next 1000 samples and do another DAQmxWriteAnalogF64. My hope was to *ignore* the first 3 calls to EveryNCallback, since those are just me "pre-writing".
What I expected to happen was that now that 3000 samples are safely in the buffer, then 1 second after I started the task, when 1000 of these samples had *actually appeared on the analog wire*, I would get another EveryNCallback, and I'd fill in another 1000 samples, which should appear on the wire 3 seconds later. That is, I assumed this pre-write would determine my effective latency.
What I find in practice is that the device *always* immediately calls my callback until it has 8000 samples, regardless of buffer size, sample rate, etc., before any data hits the actual analog wire. This is apparently the size of the internal buffer on the 6216. What I want is for it *not* to require that I fill this up before we start the task. So I learned about DAQmx<Get/Set>AODataXferReqCond. The request condition defaults to DAQmx_Val_OnBrdMemNotFull, which is consistent with the behavior I'm seeing: the 6216 really wants to fill up its buffer all the time.
I tried setting this to DAQmx_Val_OnBrdMemEmpty, which I thought would say "hey, 6216, I know your buffer isn't full, but I promise I'll keep up, please start putting samples on the wire". This doesn't throw an error, but seems to have no effect: if I immediately read the value back (via DAQmxGetAODataXferReqCond), it's still DAQmx_Val_OnBrdMemNotFull.
If this matters, calling DAQmxGetAODataXferMech tells me that I'm using USB bulk transfer. I have not tried changing this value. (Update: I tried changing this value, and USB bulk transfer is the only value that doesn't give me an error.)
So... is my mental model of how this works reasonable? Is there a way to get the latency down lower than a whopping 8 seconds?
I'm also pretty unclear on what the software buffer size (the one I configured via DAQmxSetBufOutputBufSize) even means here, since it doesn't seem to affect any of this.
Thanks!
[Update: I confirmed that if I just jack up the sampling rate, this problem largely goes away (since now filling up 8000 samples corresponds to lower latency), though in practice this is a very unsatisfactory solution, since I up the compute, bus, and memory load for no real reason. This is not an issue for generating a sine wave, but of course this is just a toy example and not what I'm actually interested in.]
-Dan
