sound input vi bug

[evren]

I am having a weird problem with long term sound input from a sound card using the Sound Input VIs.  I am reading from 2 stereo inputs (so 4 cahnnels altogether).  So I have 2 simultaneous data acquisition loops reading from two different devices (each device = 1 setero input).  When I start the program everything runs just fine.  But at unpredictible times over the course of the DAQ the inputs start to have big jumps in the signal.  I am pretty sure that it is a software problem because when I stop and restart the program everything is fine.  The jump are clearly not actual sound.  Is there any known bug with the sound input VIs that could be causing this.  Again since it happens at irregular intervals and immediately is fixed by restarting the program I don't know think its my code but rather a problem with the SondIn drivers.

I'm using LV 8.6.1 with a Marian Marc 8 Midi sound card.

[RavensFan]

I would suspect that since the sound VI's use an underlying .dll that perhaps you can't use more then one simultaneously.  Perhaps the memory space is stepping on each other.  Though I'm sure someone with better understanding of how to use .dll's or more experience with sound VI's would know better than I would.

[evren]

would reading from all 4 channels in 1 read call fix the problem?  so i call the config VI for both devices at once and read all data in 1 Sound Input Read call.

[RavensFan]

If it can be done, I think it would be better as you'd only be setting up one .dll memory space.

[evren]

i'm having issues because the sound control VI are somewhat different than NIDAQmx way of doing things.

could i ask you one more question? 

i am also doing concurant sound output with the same card.  That will use a seperate dll right?  So are there any memory overlap issues there?

and there I have to do the soudn outputs seperately so I can not join those into one playback.

thanks 

[RavensFan]

I have to reiterate that I don't know for a fact that using more than one sound input VI is causing memory space issues. I just suspect that could be the case. The sound output VI's use the same .dll, but they used different functions in the same .dll. So I don't think concurrent input and output will be a problem. However, if running multiple inputs is a problem, then multiple outputs could possibly be a problem. I don't know this for a fact, I just think it is something worth looking into, and perhaps someone with more experience with the sound VI's and how .dll's are used and called in LV might be able to step in and offer some expertise.

[evren]

yeah i got that.  i'm going to setup a simlified test program to run tonight that just reads from 2 channels seperately while playing sounds out as well to see if there is something else causing this problem in my code.

i do appreciate your help regardless though.   if this is the probem then i won't be able to do my program with the sound card since output will be an issue. 

i'll let you know.

thanks again! 

[Coq_Rouge]

I have seen this before. It is caused by a small buffer overun, in the input buffer. Create a larger input buffer

[evren]

so right now my buffer size is 1sec (44100 samples) and I'm reading 30 ms (~1300 samples) at each iteration.  so i thought that was high enough.  i'll try going higher but I've found that buffer overruns cause an error and stop input completely - is there a miniumum overrun quantity to trigger an error and stop input?

[Coq_Rouge]

---

evren wrote:
so right now my buffer size is 1sec (44100 samples) and I'm reading 30 ms (~1300 samples) at each iteration.  so i thought that was high enough.  i'll try going higher but I've found that buffer overruns cause an error and stop input completely - is there a miniumum overrun quantity to trigger an error and stop input?

---

I am not sure about the exact number. But I have observed something like you mentioned. If your program permits it you may also try to read more samples at each iteration (hence not so often as every 30ms) It may also help. I have evaluated a 24 bit sound card for medical data collection (soundcards are cheap). I have used update rates in range 50 to 100ms, and it seams to be working very stable. It was some problems then my buffer size was to low. But these problems are gone now