Needs help to improve custom analog sample generation behaviour

[pierrechatelier]

[context]

I am using NationalInstruments.DAQmx .NET API to configure and run a PCI board for custom analog sample generation.

Globally, it works, but I can't explain some unexpected behaviours, and fall into new problems each time I try to fix them.

I need help to point me things that I should have missed in the confiuration of task, streams, timings...

[use case]

My use case is the following : I have a running analog output task that can call analogMultiChannelWriter->(Begin)WriteMultiSample(...) in a loop in its own thread

A custom code can from time to time generate a new buffer of samples to change the shape of the generated signal, and submit this new buffer to the task loop

When the buffer of samples is not updated, I expect automatic regeneration to repeat the last submitted samples

I do not want to stop and restart the task, I want to keep it running, because the custom code might want to change the samples very quickly in a row, so I need minimal latency.

For the sake of simplicity, let's assume for now that the custom code generates sample buffers of fixed size. But ultimately, I want to be able to let new shapes be of any length (only the sample rate is expected to be fixed)

[basic configuration]

Let's fix things like this :

-the sample clock is 1000Hz (1 sample = 1ms)

-DAQStream.WriteRegenerationMode.AllowRegeneration is used

-UseOnlyOnBoardMemory is false for the sake of simplicity since I am not even sure that what I want to achieve would be compatible with it (or at least efficient)

-SampleQuantityMode is set to Continuous

[my observations]

As I said, it works. But I am not satisfied with what I see on an oscilloscope. I can't explain some behaviours.

Observation 1 : SampleTimingType set to SampleClock

When calling WriteMultiSample() and setting a break point just after, it can take ~10 seconds (!)  to see the signal updated on the oscilloscope. I can observe signal glitching, but this glitching does not bother me for now : the latency is my problem. I though it could be related to the size of the internal buffer set by "samplesPerChannel" when calling ConfigureSampleClock() with "SampleQuantityMode.Continuous", but it seems not to be the case. Where does this huge latency come from ?

Observation 2 : SampleTimingType set to OnDemand

When using OnDemand, I have two problems :

-(minor)the signal is not regenerated automaticaly when the custom code does not submit new samples ; it might be fixed by forcing manual calls to WriteMultiSample() (software regeneration)

-(major)the output signal does not match the sample clock. It is generated with 1sample = 1µs, which seems to be the MaxSampleClockRate of the board. It might make sense, but I do not want to scale by 1000 the size of my samples buffer ! And I do not want to manually "soft-wait" 1ms between submission of samples one by one.

I have other observations, with various tries of changing the way I call (Begin)WriteMultiSample(), wait for samples begin written, try to disable AllowRegeneration, but it only adds complexity. If only I had clues about the behaviour of Observation 1 and 2, it would be great.