06-26-2018 02:40 AM
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.
06-27-2018 03:33 PM
Hello!
Can you give some information about the hardware, drivers and where those subVI's come from?
Thank you.
06-27-2018 03:49 PM
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.
06-28-2018 04:18 AM
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.
06-28-2018 04:56 AM
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:
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.
06-28-2018 07:23 AM - edited 06-28-2018 07:25 AM
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
06-28-2018 07:51 AM
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.