Producer/Consumer Multi-Microphone Capturing

[ap8888]

I was getting buffer overflow problems when I foolishly used multiple "Capture Sound" Express VIs to listen to several mics and process them. 

I then created a producer/consumer structure where I produced 2 signals (2 producer loops) and processed them in 1 loop. It worked great!

I expanded this idea today to 3 microphones (and hoped for more later). Trouble is I'm getting errors again. I can't quite explain the errors, so I've attached images (in sequence). By highlighting execution, it seemed the error happens on the SECOND iteration of the "Sound Input Read" in each of the 3 "Producer" loops.

I hope someone can shed light on this issue. Seems strange that it would work for 2 mics but not for 3.

I briefly tried playing with the sampling rates with no apparent results.  

Message Edited by ap8888 on 03-17-2010 07:43 PM

[ap8888]

Here are the errors:

[ap8888]

Now the strangest thing happened! It worked fine for about 5 seconds. After which I was tempted to stop and start again to see if it would work. Only to get the following error:

 

Could it be that there is some buffer that's getting cleared once in a while and allows the program to run for only some time before producing another error? 

[ap8888]

I now think it's because the peak detector doesn't have enough samples in the first cycle. Therefore it causes the error. If you agree this is the error, how could I prevent this from happening? I tried adding a delay in the consumer loop, but I don't think that's the proper way of fixing this problem. 

Message Edited by ap8888 on 03-17-2010 10:30 PM

Message Edited by ap8888 on 03-17-2010 10:32 PM

[ap8888]

Could anyone shed some light?

The problem persists. 

[SMeserve]

Hi ap,

You can use the First Call VI to tell whether a section of code has been run yet.

[DFGray · Accepted solution]

Try doubling the number of samples going into the configure VI while leaving the number of points going into the read VI the same.  The configure VI sets the buffer size.  The read VI input sets how many points are read at each iteration.  The buffer should always be bigger than the number of points read so the computer has time between the buffer having enough points to read and the actual read to not overflow (which appears to be your problem).  Adding another input added more processing burden, so servicing the reads is now not occurring fast enough (the computer has less than a single sample period to respond to prevent an overflow).  I have made this mistake myself more than once.