Sound input timeout

[1984]

Hello Community,

I need to continuously acquire signals from my sound card calculate the FFT and write the sound data into wav files. I have two loops doing this, one is dedicated to acquire the signals and then it transmits the data to the second loop via a channel writer. This second loop takes care of FFT and the disk writing. (I start a new wave file in every half an hour to make sure the file doesnt grow too big).

I need to be able to run this VI for at least 24 hours, but I'm experiencing a timeout problem. I have started it twice and once it timed out after 6:12:52 and once it timed out after 6:12:54 of running (hh:mm:ss). The two seconds a difference is probably coming from some other uncertainties, so most likely it timed out exactly after the same amount of running.

I have attached a simplified version of my sound acquisition routine, which I consider super-standard and I see no reason why could it timeout. In my actual VI this section looks almost the same except of the channel writer.

This 6:12:50 looks really suspicious. Do you guys have any idea where could it came from?

Thanks.

[ChristopherBrenes]

Hello! 

Can you give some information about the hardware, drivers and where those subVI's come from? 

Thank you. 

[arteitle]

I see your sampling rate is configured for 48000 Hz, and some quick math tells me that 6:12:50 times 48000 Hz is 1,073,760,000 which is suspiciously close to 2^30 (1,073,741,824). Times two channels times two bytes per sample, that comes out to 2^32 bytes of audio data captured. That doesn't answer why it's timing out, but maybe it gives a hint. 

[1984]

These are VIs I have found in LV under Programming / Graphics & Sound / Input.

The soundcard I use is somthing Realtek High Def Audio, so nothing special.

[1984]

Impressive! I have never thought about this!

I think I have realized that I dont really know how these VIs work. As you see in my VI the reading from the sound card is in a loop so after the reading is done I will execute the next reading almost instantaneously. Because the sampling rate of the sound format is set to 48kHz I ***assume*** that the sampling rate of the sound card is 48kS/s. If this is true then each one of the readings should take about 4096/48000 = 85.3ms  

So if I measure the execution time of the sampling VI then I should see something like 85ms. And because the rest of the loop is superquick it really doesnt matter how big I set the buffer to the readings should always take about 85ms. 

So here comes the problem:

• If in the first VI (sound inpur configure) I set the Number of samples/ch to 4096 then what I wrote above is true. The exec time of the reading VI is about 85ms.
• If I set it to 8192 while I am still reading 4096 then the exec time remains pretty much the same. This makes perfect sense as - because the loop is fast - the buffer will never get full, so the reading VI actually needs to wait until the sound card has enough samples.
• If I set the Number of samples/ch to 48000, or something high then the exec speed of the reading VI drops to 1ms. Wow... that doesnt make any sense!!! Moreover if I measure the cycle time of the entire loop not just the reading VI that still displays about 1ms, while it is very obvious that the cycle is slowed down, first because the graph updates a lot slower and second because if I put an indicator to the iteration terminal then it updates lot slower.
  • 1ms doesnt make ANY sense, as no matter how big the buffer is we read faster than the sound card can sample, so the readtime should always be 85ms. 
  • This means that Number of Samples/ch input is NOT a buffer size. But then what is it really?
  • How is it possible that the loop time falls to 1ms when in reality it certainly takes more?

I think something really odd is happening here. Any help is appreciated.

I have attached the VI so you can try it on your own.

[Kevin_Price]

Wire your msec measurement into a chart and you'll see the following (at least I did):

- 1 of every 3 iterations takes a bit under 250 msec, the other 2 are negligible (~1 msec)

- in aggregate, you're getting about 12 reads per second.

- this corresponds pretty well with 48000 Hz sampling, 4096 reads at a time

I don't know exactly *why* you get this kind of timing pattern as you configure with a larger buffer size, but at least the timing makes sense in the aggregate.

-Kevin P

[1984]

Thanks Kevin, I see the pattern as well.

The buffer seems working in a very different manner as buffers work for example for daqmx. This is really odd, and I dont know if it has anything to do with the timeout issue and how can I solve that one.