What is the minimum response delay from Analog Input, via online DSP, to Analog Output?

[luojh135]

Hi experts!

    I want to know whether it is possible to achieve a very fast reponse latency (~ 1 ms) from Sound Recording (Analog input), via online processing the recording (Online DSP), to Sound Presenation (Analog output), using the DAQmx programming codes. My NI system includes NI PXIe 8135 Controller, PXIe 6358 Multifunctional DAQ, and PXIe 5412 Arbitrary Waveform Generator. I also have access to the latest Labview software (Version 2015).

    My project is about auditory perturbation, which inovles recording the vocalizations, manipulating the recorded vocalziations, and then presenting the manipulated vocalizations. My current idea of how to achieve this purpose is doing triggered voltage output after reading the input samples using DAQmx Read. The output of DAQmx Read is online filtered, and then passed as input for DAQmx Write for analog output. For illustration purpose, sample codes are presented below. Note, for simplisity, the codes for triggering part are not presented here. It is something to work in the future.

    My question here is whether the above idea suitable to achieve ~ 1 ms of delay? Or I have to rely on a totally different programming module, such FPGA? I am very new to Labview as well as to NI. After reading some documentations about FPGA, I realized that my current hardware can't do it because I don't have FPGA signal processing hardware. Am I wrong?

    Something might be important to mention, I am sampling with microphone array (about 16 mics) at very high sampling rate (250 kHz), which is technically very high througput. Natually, these recordings have to be saved to hard drive. Again here, only one microphone is illustrated.

    I have two concerns that my current approach might achieve my goal.

    First, for the DAQmx Read function in step 2, I set the samples to read as 1/10 of sampling rate. This is recommended by Labview and thus necessary to avoid overflow of the buffer when a smaller number is used. However, my concern here related to the response latency is that this might already cause a reponse delay of 100 ms which is the time to collect these samples before reading. Is it true?

    Second, each interaction of the while loop takes at least a few dozens of milliseconds (~30 ms). Is it causing another 30 ms of delay?

[Bob_Schor]

When you take N Samples at a rate of R KHz, you get an array of N numbers every N/(1000*R) seconds.  In particular, if you acquire 25,000 samples at 250 KHz, you will get 25,000 points every 100 msec.  So your ability to make a waveform that even duplicates the input will have a 100 msec delay "built in" (I'm assuming the NI hardware can't "predict the future" of its inputs).  The only way to shorten what I'll call the "sampling delay" is to shorten the sample.

But you also talk about filtering the input signal.  For this, you need a minimum number of points, so this imposes a lower bound on the sampling delay.  Filtering also cannot "predict the future", so most filters operate on the current and previous points.  This introduces "edge effects" when considering a finite signal -- for example, if I'm using a 5-point moving average of a 1000-point waveform, I only have 995 5-point "samples" to work with.  If I wanted to do this in a "continuous" manner, I could do something like "Take two 1000-point samples, do the 5-point Moving Average on the first 1000-point set (starting with points 1-5 and ending with points 1000-1004, four of which come from the second set of data), then shift everything down 1000 points, add another 1000-point sample at the end, and do the next 5-point-on-1000-points Moving Average.  But this means additional delays or notable variations in the Filter properties.

Your delay will ultimately be determined by the nature of your filter.  In the Fastest Of All Possible Worlds, you would create a (circular) buffer of a width wide enough for your filter, say M points.  You would sample fast and do processing between each sample (did I hear someone say FPGA?).  Once the Buffer had been filled, you would "process" the buffer to create the next "filtered" output point and output it.  This would mean that your Output signal would be delayed by M Sample Times from the input signal, but if the sampling time was 250KHz and M was 250, this would be a 1 msec delay ...  Of course, you need a D/A system sufficiently "fast", as well, and I think these are harder to find ...

Bob Schor

[charansai]

Hi there,

I cannot answer the whole question, I am not an expert in this topic, I am also new and working now like you(not exactly !!) on audio processing. But here is what I know.

- It is not possible to achieve 1ms latency through Host VI.

- If you want do it on RT side, you can use frame based processing. I mean you can collect bunch of data and process it at one time. As you said you are sampling @250 kHz , you can process <250 samples each time to get latency of 1msec. Again, any heavy processing on data could kill the time.

I personally, through my little experience suggest you to go for FPGA if you can get your DSP algorithms running on FPGA .

One main reason is its quick processing and other being these high sample rates are normally supported with FPGA.  The two downsides being the difficult to code and you can not do any post data processing. For observing and all, you have to use DMA FIFO transfers from FPGA to RT side and then do the processing ! 

Hoping that this will give you a bit of more clarity !

Thank you.

[luojh135]

Dear Bob,

    Thanks for your reply.

    I get your point that reading 25000 samples will cause a delay of 100 ms for sampling rate of 250 kHz. I tried to reduce the samples of reading each time, but it seems that the smallest number I can reach without causing the over flow problem is around 1500, corresponding to a delay of 6 ms. That's it! Can I draw the conclusion that I can't go faster than 6 ms with the present programming module?

[luojh135]

Hi, thanks for the comments.

I liked your comment that '' It is not possible to achieve 1ms latency through Host VI.". This is a concise but very important answer to my question. So I don't need to waste time trying to optimize the DAQmx codes for faster response delay.

Could you talk more about the real-time (RT) solution? I've heard "frame based processing" but never used it so far. You suggested me to go for FPGA module. Could you please have a look at the hardware list that I posted during the original email to see whether it is possible with the current hardware? My feeling is that it is probably not possible, because I don't have any hardware there for signal processing. I am not confident to draw this conclusion due to my limited knowledge about FPGA.

[charansai · Accepted solution]

Hey, I have never used or familiar with the hardware you have. So, I can't help you there.

About RT side, again I don't know about your hardware but I was using NI myRIO 1900, where it has a specific  High Throughput personality on RT where I can acquire the Audio @44 kHz and process the data. Frame based processing is eventually doing the processing on a large array of audio data that you have collected through high sampling rate and as many number of samples as allowed by latency, please check this . 

I wasted around 2 weeks to figure out that Host side does not work and another 2 weeks to figure out that even RT side does not work for Online(real time) processing. So, eventually now I am working on FPGA, where sampling rate is 250 kHz (of course shared by several channels).

The complex thing with FPGA is coding, please check if the filter that you want is given below as labview automatically generates some codes for certain filters.

Most of these will work in 1 SCTL i.e if your target has 40MHz clock the algorithm will be executed in 25 nsec. This is what I was looking for, hopefully you 🙂 

Cheers ..!

[luojh135]

Hi, thanks again.

It is a lot of new information and it will take me some time to digest. But I am glad that you pointed me the right direction. I might get back to you in some days or weeks.

[charansai]

Happy to help 🙂

Please cross check the numbers again and decide. Choose a hardware which suits your sampling rate and processing time and so on..

All the best !