Will a Dedicated Target (ETS) Reduce Latency for PCI 4472 ?

[cdschmit]

Hi,

I recently started playing around with a PCI-4472 board in standard LabVIEW 8.2.  The code I am using for basic two-channel I/O uses the SigmaTel audio (on the motherboard) for playback of a two-channel microphone input.  At 16 kHz sampling, it seems that I need to acquire data chunks around 4000 samples/ch to achieve "real-time" output (that is, the buffer on the 4472 doesn't start to fill as the output lags the acquisition).  I was not able to find much information regarding the SigmaTel audio, so I tried a sampling rate of 11025 Hz with similar results.  For our application, this 1/4 second latency is too costly.

Will placing the 4472 into a dedicated target (ETS) significantly reduce the latency?  (For simple "pass-through" I/O, I wouldn't want more than a few milliseconds!) For AI/AO applications, do you suggest using a single card (not the 4472) that has both Analog Inputs and Analog Outputs available?

Thanks in advance for your help!
Chris

[Sandra_T]

Hello Chris,

I see that you are using the PCI-4472 and would like to acquire input from a microphone and output the acquired signal using the SigmaTel Audio on your motherboard. Can you please clarify are you acquiring from two channels and outputting on two channels? What is the rate that the SigmaTel audio device capable of? What is the frequency of the signal you are trying to measure? What sampling rate do you want to achieve?

Are you using the Play Waveform express VI? From here you can tell what the min sampling rate and max sampling rate for your device is. On my system, the min was ~44.1k and max ~ 192kHz

Are you having problems acquiring samples or playing the data back?

If you wanted to acquire and generate on the same card then you would use the NI 4461.

Regards,
  Sandra T.

Applications Engineer | National Instruments

[cdschmit]

Sandra T.

I see that you are using the PCI-4472 and would like to acquire input from a microphone and output the acquired signal using the SigmaTel Audio on your motherboard. Can you please clarify are you acquiring from two channels and outputting on two channels?

Yes two channels of audio (voice) input, two channels of audio output.

What is the rate that the SigmaTel audio device capable of?

I don't know min and max, but 16 kHz works.  I'll try the Play Waveform.vi to check when I get back to my office later, but I don't think this relates to the problem.

What is the frequency of the signal you are trying to measure? What sampling rate do you want to achieve?

Acoustic voice...8 kHz is enough, thus the 16 kHz sampling rate.

Are you having problems acquiring samples or playing the data back?

I suppose we could concentrate on the acquisition side.  I need to acquire and playback in real time with low latency (below a few milliseconds).  When I configure for continuous sampling and request small block sizes (low latency), the DAQ buffer begins to fill and will eventually overwrite thus causing continuous acquisition to fail.  I suspect there is an "overhead" associated with acquisition of the data chunks and the "sweet spot" occurs for block sizes on the order of 4000 samples (1/4 second), at least on my machine when analog output is enabled simultaneously.

If you wanted to acquire and generate on the same card then you would use the NI 4461.

Yes, I know, but my question was more or less about the latency.  Does this problem go away when moving to a desktop-based RTOS?  Will the desktop solution even work with a sound card output?  If so, then I don't need to switch cards. 

In talking with another NI engineer over the phone, it seems that the latency most likely limited to the Windows (non-RTOS) use and should be much better with a dedicated desktop (ETS).   There are serious questions about trying to use the sound card for synchronized output in RTOS...may be better off purchasing another card for AO and synchronizing the two with a ribbon cable.  Still, I'd be curious to know if that's the best we can do with a Windows system and what I might expect with the RTOS.

Thanks for the reply,

Chris

[preston_johnson]

try sending the data from the 4472 thru a queue - this will allow the inputs to decouple from the outputs, allowing the acquisition to proceed without failing and allow the sound card outputs to proceed at its own pace. 

[cdschmit]

Preston,

try sending the data from the 4472 thru a queue - this will allow the inputs to decouple from the outputs, allowing the acquisition to proceed without failing and allow the sound card outputs to proceed at its own pace. 

 
I have actually tried that...doesn't help as far as the latency is concerned.  In addition, if you separate the input and output but don't (can't) synchronize the clock of the 4472 with that of the sound device, you will have likely have AI running away from the AO or "skips" in AO in the reverse case.  I am returning the 4472 in favor of building a cRIO system, so the problem of fixing the 4472 now becomes purely academic (to me).  I have more or less been assured that the latency will be much lower in any of the real-time solutions.

Thanks to everyone who has assisted me!
Chris